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TITLE: METHOD AND APPARATUS TO OBTAIN SERVICE CAPABIUTY CREDENTIALS 



BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to distributed computing environments including Web-centric and Intemet^entric 
distributed computing environments, and more particularly to a heterogeneous distributed computing environment 
based upon a message passing model for connecting network cUents and services, and tbe discoveiy of services in 
such an environment 

2. Description of the Related Art 

Intelligent devices are becoming increasingly common. Such devices range from smart appHances, 
personal digital assistants (PDAs). ceU phones, lap top computers, desktop computers, workstations. mainfiBmes; 
even, super computer. Networks are also becoming an increasingly common way to interconnect intelligent 
devices so that they m^y communicate with one another. However, ther«*may be large differences in the computing 
power and storage capabilities of various intelligeiit devices. Devices whh more limited c^abilities may be referred 
to as small footprint devices or "diin" devices. Thin devices may not be able to/ participate in networks 
interconnecting more capable devices. However, it may still be deshable to mterconnect a wide variety of different 
types of intelligent devices. 

Hie desire to improve networking capabiUties is ever increasing. Business networks are expanding to 
include direct interaction witii suppliers and customers. Celhilar phones, personal digital assistants and Internet, 
enabled computers are : commonplace in both business and tiie home. Home networks are available for 
interconnecting audio/visual equipment such as televisions and stereo equipment to home computers, and other 
devices to control intemgent systems such as security systems and tempera^ High bandwidth 

mediums such as cable and ASDL enable improved services such as Intemet access vi^^^ 

etc. Network ^sterns are becoming pervasive. Even without a formal network, it is stiU desirable for intelligent 
devices to be able to communicate with each other and share resources. 

Cuirentiy, traditional networks are complex to set vp, expand and manage. For example, adding hardware 
or software to a network often requires a network administrator to load drivers and configure systems. Making 
small changes to a networic configuration may require that the entire networic be brought down for a period In 
addition, certain intelligent dwices may not support the necessary interfeces to communicate on a given network. 

What is needed is a simple way to connect various types of intelligent devices to allow for communication 
and sharing of resources while avoiding interoperability and complex configuration problems existing in 
: conventional networks. Vmous technolo^es exist for improvmg the addition of devices to a network. For 
example, many modem I/O buses, such as the Universal Serial Bus, 1394 and PCI, support plug and play or 
dynamic discoveiy protocols to simplify the addition of a new device on the bus. However, tiiese solutions are 
Uimted to specific peripheral buses and are not suitable for general networks. 

A more recent technology, Jini from Sun Microsystems, Inc., seeks to simplify die connection and sharing 
of devices such as printers and disk drives on a network. A device that incorporates Jini may announce, itself to the 



WOOl/86394 PCT/USOl/15134 

networic may provide some detaUs aboiit its capabilities, and may immediately become accessftle to other devices 

onthenetwork. Jini allows for dislribmed computing where the capabilities of the various devi^^ . 

network. The Jini technology seeks to enable users to share services and resources over a network. Another goal of 

the Jini tedmology is to provide users wift easy access to resources anywhere on flie netwoik wMe allowing tiie 
5 netwoik location of the user to change, Jini also seeks to simplify the task of buflding, maintammg and altering a 

netwoik of devices, software and users. 

Jini requires that each Jini enabled, device have a certain amount of memory and procesang power. 

Typically, a Jmi enabled device is equipped with a Java Virtual Machine (JVM). Thus. Jini systems are Java. 

technology centered. Java is a Mgh level object oriented programming language developed by Sun Microsystems, 
10 toe Java source code may be compiled into a foimat called bytecode, whidi may Aen be executed by a Java 

Virtual Machine. 

Bytecode is computer source code that is processed by a ^dltual machine, rather than the "r^^ 
machine, the hardware processor. The vhtoal machine converts generalized machme uistruction (flie bytecode) mto 
specific machine instructions (instructions that the computer's processor wiU understand). Using a language that 
15 comes with a virtual machine for each platfonn. the source language statements may be compn^ 

flien run on any platform that supports the virtual machine. The Java programming language is an example of such a 
language, and the Java Virtaal Machine (JVM) is an example of a virtual machine platform fliat supports programs 

written in the Java programming language. 

Since Java Vutual Machmes may Ix: provided for most computmg platfonns, Java and flius Jmi prow^^ 

20 for a certain amount of platform independence. The Jini architecture leverages off the assumption that the Java 
programming language is the implementation language for the components of the Jmi system. The ability to 
^amicallydowiUoad and nm Java code is central to many features of the Jmi architectare. 

The puipose of th6 Jini architecture is to federate groups of devices and software components into a single, 
dynamic distributed system. A key concept withm tiie Jmi architecture is that of a service. A service is an.entity 

25 that can be used by a person, a program, or another service. Two examples of services are printing a document and 
translating from one word processor fonnat to another. . Jim allows the members of a Jini system to share access to 
services. Services m a Jmi system communicate with eadi ofter by using a service protocol, which is a set of 
interfeces written in the Java programming language. Services are found and resolved in a Jini system by a lopk-up 
service; A look-up service maps interfeces indicating the fimctionality provided by a service to sets of objects that 

30 inqdement the service. 

Descriptive entries msy also be associated with a service. Devices and appUcations use a process known as 
discovery to register wifli the Jmi network. Once registered, fte device or apphcation places itself in &e look-iq) 
service. The look-up service may store not oatf pointers to these services <hi the network, but also inay store tiie 
code for accessmg tiiese service. For ejan^le. when a printer registers witii ^e look-^) service, it loads its printer 

35 driver and/or an interfece to the driver mto the look-up service. When a cheat wants to use the printer, the driver 
and driver mterfece are downloaded from the look-up servfce to the client This code mobility means that cKents 
can take advantage of services ftom the network without pre-instaUing or loading drivers or other software. 

Communication between services in a Jini system is accon?)lidied usmg the Java Remote Method 
Invocation (RMI). RMI is a Java programming language enabled extension to traditional remote procedure call 

40. mechanisms. Wvfl aUows not only data to be passed from object to object around the Jini network, but M 
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including code as weU. Jini systems depend upon this ability to move code around the network in a form that is 

encapsulated as a Java object 

Access to services in a Jini system is lease based. . A lease is a grant of guaranteed access over a to^^ 

lease is negotiated between the user of the service and the provider of the service as part of the service protocol. A 
5 service may be requested for some period and access may be granted for some period presumab^ 
. request period. Leases must be renewed for a service to remain part of the Jini system. 

Figure 1 iUustrates the basic Jini technology stack. The Jini technology defines a distributed programming 
model 12 (supported by JavaSpaces. leases, and object templates). Object communication in Jini is based on an 
RMI layer 14 over a TCP/IP capable networking layw 16. 
10 Jini is a promising technology for simplifying distributed computing. However, for certain types of 

devices, Jini may not be appropriate, lie computing landscape is moving toward a distributed, WebK«ntric service 
and content model where the composition of cUent services and content changes rapidly. Hie cUent of the future 
may be a companion type device that users take with them ^erever they go. Such a device may be a combination 
of a cell phone and aPDA for example. It would be desirable for such devices to be able to communicate and share 
15 resources with devices that are more powerftl, as weU as with thinner or less powerfiil devices. 

In addition, with the advent of the Intemet and resulting explosion of devices connected to the net, a 
distributed programming model designed to leverage this phenomenon is needed. An enabling technology is needed 
ftat facilitates clients connecting to services in a reliable and secure fashion. Various clients from thick to thin and 
services need to be connected over the Internet, corporate Internets, or even within single computers. It is desirable 
20 to abstract the distance, latency and implementation from both clients and services. 

nie key chaUenge for distributed computing technology is to be scalable from powerfol thick cUents down 
to veiy thin cUents such as embedded mobile devices. Current distributed computing technologies, such as Jini, may 
not be scalable enough for the needs of all types of cUents. Some devices, such as small footprint devices or 
mbedded devices, may lack sufficient memory resources and/or lack sufBdent networidn^ 
25 satisfectorily m current distributed computing technologies. TTie low end of the client spectrum, including 
embedded mobile devices, often have Umited or fixed code executioii environments. Hiese devices also may have 
minimal or no persistent storage capabilities. Most small, embedded mobile devices do not support a Java Virtual 
Machine. Most code^^apable small cUents run native code only. In addition, most smaU devices have Utde more 
. than flash memory or battery backed RAM as their sole persistent storage media. The size of the storage is oflen 
30 very small and sometimes read-only in natm^ Furthermore, the access time of dus type of storage media is often an 
order of magmtude greater than hard disk access time in cUents ^ are more powerful. 

Existing connection technologies, such as Jmi, may not be as scalable as desired because they are too big. 
For example, Jini requires tiiat all participants support Java; however, many sman ciie^ 

for a Java Virtual Machine. Furthermore, due to its use of RMI, rmi requires that cUents be able to download code 
35 ' and content Jini may augment the existing cUent platform by downloading new classes, which may pose security 
and size concerns for small devices such as embedded devices. Jmi works by cUents and resources communicating 
by passing code and data. When a cUent activates a Tmi service, the service may return its results to the client, 
vAidi may inchide a large amount of code or content In Jini, a cUrtt may caU a meftod^^^^ 
retpmed, and thus dovmloaded. ITie cUent may not have 4e resource to accq?t the returned object In addition. 
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RMI and Java itself require a lot of memory. Many small foot print devices may not. have, the resources to 
participate effec^veiy or at aU in current distributed computing tedmologies. 

Another concern Avith existing distributed computing technologies is that they often require certain levels of 
connection capability and protocols. For example, Jini assumes the existence of a network of reasonable speed for 
5 comiectmg computers and devices. Jini also requires devices to support TCP/IP network, transport protocol. 
However, many smaUer devices may have limited connection cq)abilities. SmaU devices may have high latency or 
low speed network cormections and may not support TCP/IP. 

As mentioned above, Jini requires devices to support Java and thus include a Java Virtual Machme, v^ich 
requires a certain amount of processing and storage c^abilities that might not be present for many small devices. 
10 This also restricts the flexibility of Jini in that non-Java devices may not directly paiticQ)ate in a Jini system. Since 
Jini requires Java, it may be deemed a homogenous environment However, it is desirable to have a distributed 
computing facility for heterogeneous distributed computing that scales from extremely small embedded devices 
through PDA's and cell phones to laptops and beyond even to the most powerful computers. 

Oflier heterogeneous solutions exist, such as the Common Object Request Broker Architecture (CORBA). 
15 CORBA is an architecture that enables program objects to communicate with one another regardless of the 
programmmg language they were written in or what operating system tibey 're running on. However, CORBA does 
not address all of the connection issues that are addressed by Jini. In addition, CQRBA suffers from similar 
scalability problems as Jini. 

Technology such as Jioi and CORBA use a code-centric programmmg model to define the interfece. 
20 between remote components. A code-centric programming model defines programmatic mterfeces or API's for 
communication between remote clients or components. The APPs may be defined m a particular ^programming 
language. The API's must be agreed to by all software components to ensure proper mteroperability. Since all 
access to componerits is through these standards API's, the code that inq)lements tiiese API's must be present in the 
cHent platform. Tlic code may be statically linked into the platform or dynamically downloaded when needed. 
25 Many embedded or mobile devices simply cannot accept code dynamically from a network due to fee quality control 
issues iuvolved as well as the reliance on a single language and program execution envnonment Data-centric 
models, such as networking protocols, may avoid tiie dependence on moving code; however, such protocols are not 
rich enough to easily provide for distributed computmg and they also lack the ease of programming witii code and 
other programiiurig features, such as type safety. 
30 Conventional distributed computing systems rely on the ability of a program executing on a first device to 

be able to remotely call a program on a second device and have the results returned to the first device. The Rmote 
Procedure Call (RPC) is a basic mechanism for remotely calling a program or procedure. CORBA and Jini are both 
based on tiie ability to remotely invoke program methods. However, communicating by passing code or objects, 
such as in Jini or CORBA, may be somewhat complex. For example, as mentioned above, Jini uses the Java Remote 
35 Method Invocation (RMI) to communicate between services, in ordo* for a client to move Java objects to and from 
remote locations, some means of serialization/deserialization is needed. Such current fecilities in the Java 
Development Kit (JDK) rely upon the reflection API to determine the context of a Java object, and ultimately that 
code must consult the Vhtual Machine, This code is quite large and inefiBcieiit 

The fundamental problems with the current method for doing serialization/deserialization include its size, 
40 speed, and object traversal model. Code outside tiiie JVM does not know tiie structure or graph of a Java object and 

■ 4 
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thus must traverse the object graph, puUing it apart, and ultimately must caU upon the JVM. Traditional 
serialization and reflection mechanisms for storing and movmg Java objects are just not practical for all types of 
devices, especially thinner devices. Some of the difficulties with Java reflection and serialization are that an 
object's graph (ah object's transitive closure) reflection is difficult to do outside the JVM. Serialization is too large, 
5 requiring a large amount of code. In addition, serialization is a Java specific object interchange fonnat and thus may 
not be used with non-Java devices. 

The Jini distributed computing model requires the movement of Java objects between Java devices. Thus, 
the serialization mechanism itself is not platform independent smce it may not be used by non-Java platforms to 
send and receive objects. Serialization is a homogenous object format - it only worics on Java platforms, 
lb Serialization uses the reflection API and may be limited by security concerns, which often must be addressed using 
native JVM dependent methods. The reflection API may provide a graph of objects, but is inefficient due to the 
number of calls between the JVM and the code calling the reflection metiiods. 

The use of Java reflection to serialize an object requires an application to ping pong in and out of the JVM 
to pick apart an object one field at a time as tiie transitive closure of the object is (ftTiamically analyzed 
15 Deserializing an object usmg Java deserialization reqmres the application to work closely with the JVM to 
reconstitute the object one field at a time as the transitive closure of tiie object is dynamically analyzed. Thus, Java 
serialization/deserialization is slow and cumbersome v\Me also requiring large amounts of application and JVM 
code as well as persistent storage space. 

Even for tiiin clients that do support Java, Ae Jini RMI may not be practical for thm clients with mimmal 
20 memory footprints and minimal bandwidth. The serialization associated witii the Jini RMI is slow, big, reqmres the 
JVM reflection API, and is a Java specific object representation. Java deserialization is also slow, big and requires 
a serialized-object parser. Even Java based thin cUents may not be able to accept huge Java objects (along with 
needed classes) being returned (necessarily) across the network to the client as reqmred in Jini. A more scalable, 
distributed computing mechanism is needed. It may be desirable for a more scalable distributed computing 
25 mechanism to address security concerns and be expandable to allow for the passing of objects, such as Java objects, 
and even to allow for process migration fix)m one network mode to another. 

Object based distributed computing systems need persistent storage. However, as discussed above, 
attempts at object storage are often language and operating system specific. In addition, these object storage 
systems are too compUcated to be used with many small, embedded systems. For example, the Jmi technology uses 
30 JavaSpaces as persistent object containers. However, a JavaSpace can only store Java objects and cannot be 
implemented m smaU devices. Each object in a JavaSpace is serialized and p^s the above-described penalties 
associated witii Java serialization. It m^ be desirable to have a heta-ogeneous object repository for distributed 
computing tiiat may scale from small to large devices. 

JavaSpaces fi-om Sun Microsystems, Inc., draws from the parallel processmg work of David Gelemter, a 
35 computer science professor at Yale University. Gelemter's set of functions named "Linda" create a shared memoiy 
space called a TupleSpace, in which resufe of a computer's processes or the processes themselves may be stored for 
access by multiple CPUs. Linda therefore provides a global shared memory for multiple processors. 

Anotiier technology which extends Linda is TSpaces fcom IBM Corporatioru TSpaces extends the basic 
Linda TupleSpace jframework wifli real data management and the ability to download new data types and new 
40. semantic functionality. TSpaces provides a set of networic communication bufto and a set of APIs for access 
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those buffers. Like many of the sohitions discussed above, TSpaces therefore uses a code-centric programming 
model and shares the drawbadcs of such a model. Additionally, TSpaces is implemented in the Java programming 
language and therefore requires a Java Virtual Machine or other means of executing Java bytecode, such as a Java- 
capable microprocessor. Therefore, TSpaces may be mappropriate for small-footprint devices \\tich cannot devote 
5 . sufficient resbmrc^ for executing Java bytecode. 

It is desirable in object oriented distributed systems to be able to locate object repositories and find 
particular objects within those repositories. As mentioned above, the Jini look-up server may not be practical for 
small devices with small memory foo^jrints. A more efBcient mechanism for locating object stores may be 
desirable. 

10 It may be desirable m a distributed network computing model for clients to have the ability to locate 

services. Current network protocols either provide only a single standard service access uiterfece that provides no 
security when accessing a network service or provides "all or noting** access to the full range of die service's 
capabilities. Which may include administrator or privileged functions. Also, current network protocols to locate 
services do not provide a flexible mechanism for finding services. Current protocols cither do not provide any 

15 selective search capability at all (e.g. UPnP) or only provide a primitive keyword and attribute grammar mechanism 
(e.g. SLP). Thus, current service discovery mechanism may be too inflexible m their security and search criteria 
mechanisms. 

Also, current service discovery models have a symmetric model for service location. However, it may be a 
waste of resources for certain service devices, such as devices whose functionality is available on a proximity basis, 
20 . to support the discovery model. This is because such devices are ahea^ located by proxnnity (e.g. one device 
physically pointing to another one). Thus, an alternate light-weight discovery mechanism may also be desirable for 
such devices. 

Distributed object access also desires a fair and efficient sharing mechanism. As described above Jini 
currently uses a leasmg mechanism to 'share objects. However, Jini leases are time based which may result m a 

2i5 number of problems. For example, die current object holder might have no idea how long to lease an object and 
inay hold it too long. In addition, the use of time-based leases may require that thne be synchronized between 
multiple machines. Moreover time based leasmg may requb^ operating system support. In addition, Jini leases are 
established arid released via RMI. Thus, the Jini leasing mechanism suffers from the above-noted problems with 
using RVH. In addition, the Jini leasmg mechanism does not provide a security mechanism for establishing, 

30 renewing and canceling of leases. Other leasing mechanisms may be desuable. 

Generally speaking, it is desirable for snaall memory foot print mobile client devices to be able to run a 
variety of services, both legacy and new, in a distributed environment The types of small clients may inchide cell 

: phones and PDA*s with a variety of different networking interfeces, typically low bandwiddi. Often these devices 
have very small displays with limited grs^hics, but fhey could include laptops and notebook computers, which may 

35 have a larger display and more sophisticated graphics c^abilities. The services may be a wide range of applications 
as weU as control programs for devices such as printers. It is desuable for a mobile client to be able to use these 
services v\^erever they may be. 

A mobile client will often be at a temporary dynamic network address, so networking messages it sends 
cannot be routed beyond that networking interface (otherwise there may be collisions when two different clients on 

40 different networks have the same dynamic address). Mobile clients often do not have the capability for a fiill 
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fonction bK,wser or other sopWsticated softvvaie. . The displays may limit the cUent. from rmmmg certain 
applications. Itaditional appUcation mbdeb ar« based on predetennined user interfi«:e or data cha^ Any 
change to the application requires recompilatioa of the application. 

It my be desirable for such cUents to have a mechanism for finding and mvoking distributed appUcaticms 
5 or services. Tie client may need to run even large legacy appUcations which could not possibly fit in the cUent's 
memory footprint As discussed above, current technology, such as Jini, may not be practical for smaU footprint 
devices. Tie pervasiveness ofmobDe thin cUenIs may also raise additional needs. For example, it may be desirable 
to locate services based on the physicd location of the user and his mobile cUent: For 

the services in a local vicinity may be. very helpH such as local restaurants, weather, traffic maps and movie 
10 mformation. Similarly, information ax>ut computing resources, such as prto^^ 

helpM Current technologies do not provide an automatic mechanism for locating services based ori physical . 

locadon of the cUerit Another need raised by thin mobaecUenIs is that of addre^^^ Ti^ 

mobile cUents typically do not contain crsonomic keyboards and monitors. Tbe provision of such hmnan fector 

services and/or the abiUty to locate such services in a distributed computing envto 
IS A distributed computing model shouldprovide clients with a way to find transient documents and services. 

It may be desirable to have a mechanism for finding generd-pmpose documents (includi^ 
advertisements), where the documents are expressed in a platfomi-independent and languag^mdependcnt typing 
such as that provided by eXtensfcle Markup Language (XML). Current approac^^^ 

for rmi. Universal Plug and Play (UPnP). and the Service Location Protocol (SLP). do not support such a general- 
20 purpose document lookup mechanism. For example, the Jinilookup mechanism is Umited to Java Language typing 
' and is therefore not language-independent l*nP and SLP support a discovery protocol only for services, not for 
genraal-purpose documents. 

SUMMARY 

to a distributed computing enviiomnent, a service discovery protocol may aUow cUents to search for 
25 services (both space services and specific services or types of services). Service providers (or a listener agent) may 
respond to search requests by pubUshing or providing corr«ponding advertisements or URIs to corresponding 
advertisements. When a service provider responds to a discovery search request (dther directly or ti^ 
agent), the provider may choose to pubUsh a protected or an un-protected (complete) advertisement A protected 
adverkment may include the set of m&rmation necessary to obtain a complete advertisa^ PubUshmg a 
30 protected advertisement, forces the cUent to the obtain a valid credential from an authentication service before 
receiving the complete m^protected advertisement from the service provider. A complete nn-protected 
advertisement is needed to create a gate, and therefore to use die service. Forcing cUcnts to obtain a valid credential 
befor^receivinganadvertisementmayprovideanadditionallevelofsecuriQrforthese^^^ Thesecurity 
credential that must be obtained to receive the complete advertisement may be the same security credential that is 
35 used to construct a gate to communicate with the service where the gate embeds flie security credential m each 
message to the service. 

To obtain a complete advertisement, given a protected advertisement, a cUent obtains a capability 
cfedentialfromlfaespecifiedauthimticationservicebysendingacredential^ Tbc credential request 

message may be sent to an authenticated service UW specified in the adve^ 
40 to access. When the client's request is received, a capabiUty credential is generated. Hie capabUity credential may 
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be generated according to capabilities requested by the client and/or the client's level of authorization; The cUent 
then receives the capabiUty credential in response, to its request Hie response may contain the credential needed to 
genemte the complete advertisement TTus credential may be the same credential that the client's gate mchides in 
each message sent to the service. If the advertisement was a protected advertisement, the cUent then may send an 
advertisement request message contamingthe capability credential and an identification (e.g. UUID) of the service 
to the second URI specified m the protected advertisement The cUent then receives a complete advertisement TTie 
response to this second message is the complete advertisement of the specified service. Ttie complete advertisement 
. and the capabiUty credential may then be used to create a gate used to coinmunicate with 

In m.e embodhnent, a method for accessing a service in a distributed computing enviromnent may mclude a 
cUent locating a first service within &e distributed computing enviromnent To locate services, the client inay send 
a search message in a data representational language. Tlie search message may include search criteria, such as 
service name and service type criteria. Services or a listener agent receiving the search message may compare the 
search criteria to service advertisements • to find advertisements that match the search criteria. Service 
advertisements may be data representational language docmnents that provide access information for coirespondmg 
services. Hie cUent may then receive seardi response messages which indicate advertisements that matched the 
search criteria. 

The client may then select a service that is desired to be accessed and request a capability credential to 
aUow the cUent to access some or all of that services capabUities. Tlie cUent may send a capabiUty credential 
request message to a UM specified in the selected service advertisement. Tliis URI may be an authentication 

10 service. Iftheadve,tisementwasacompleteadvertisememinchidingschemainf<mnationform^ 

service, then the client may receive a capabiUty credential for accessing the services complete capabiUties. If the 
advertilement was a protected advertisement which does not include access schema informat^^ 
include within its c^abflity credential request message an indication of a set of desired capabiUties for which it 
desires permission to access firom flie service. 

25 A client then receives the capability credential which indicates that flie cUent is allowed to access at least a 

portion of the services capabiUties. TTie capabmties for which the cUent is aUowed access may be the le^^ 

set of capabilities which the client requested m its capabiUty credential request message and the set of oipabilities 
for which the cUent is authorized. If the original advertisement indicated m the response to the cUents search 
message was not a complete advertisement, the client then uses the capabiUty credential to request a complete 

30 advertisement for its granted capabiUties. The cUent may send a advertisement request message to a URI specified 
in the protected advertisement A service provider receiving the advertisement request message may generate a 
custom complete advertisement for tiie capabiUties indicated by the cUcnts capabiUty credential and retmn this 
complete advertisement to the cUent Tlie cfient may then construct a message gate based on the complete 
advertisement for sendmg messages according to the schema m the complete advertisement to access the services 

35 capabilities. TTie gate may include the capabUity credential in each message so that its messages may be 
auftienticatedby the service. , 

BRIEF DESCPTPTf ON OF T HE PRAWINCS 

Figure 1 is an illustration of a conventional distributed computing technology stadc; 
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Figure 2 is an illustration of a distributed computing environment programming model according to one 
embodiment; 

Figure 3 is an illustration of messaging and net\yoridng layers for a distributed computing environment 
according to one embodiment; . . 

5 Figure 4 is an illustration of a discovery service for finding spaces advertising objects or services in a 

distributed computing environment according to one embodiment; 

Figure 5 Ulustrates client . profiles supporting static and fonnatte^^ 
environment according to one embodiment; 

Figure 6 is an illustration of a distributed computing model employing XML messaging according to one 
10 embodiment; 

Figure 7 illustrates a platfonn independent distribudng computing environment according to one 
embodiment; 

Figure 8 is an illustration of a distributed computing model in which services are advertised m spaces 
according to one embodiment 

15 Figure 9 is an illustration of a distributed computing model in which results are stored in spaces according 

to one embodiment; 

Figure 10 is an illustration of client and service gates as messaging endpoints in a distributed computing 
model according to one embodiment; 

Figure 10b is an illustration a message endpomt generation according.to a schema for accessing a service 

20 . according to one embodiment 

Figure 1 la iUustrates gate creation in a distributed computing environment accordin 

Figure 1 lb illustrates gate creation and gate pairs in a distribirted computing environment according to one 

embodiment; 

Figure 12 is an illustration of possible gate components in a distributed computing envnonment according 
25 to one embodiment; 

Figure 13 is an illustration of proxy client for a conventional browser to participate in the distributed 
computing environment according to one embodiment; 

Figure 14 illustrates the use of a method gate to provide a remote method invocation int^ce fo a service 
in a distributed computing environment according to one embodiment; 
30 Figure 15 is an illustration of the use of a space in a distributed computing environment according to one 

embodiment; 

Figure 16 illustrates advertisement structure according to one embodiment; 

Figure 17 illustrates one example of advertisement state transitions that an advertisement may undergo 
during its lifetime accordmg to one embodiment; 
35 Figure 18 is an illustration various space location. mechanisms in a distributed computing envinmment 

according to one embodiment; 

Figure 19 is an illustration of space federations in a distriSjuted computing environment according to one 

embodiment; 

. Figure 20 is a flow diagram illustrating client formation of a session with a space sendee in a distributed 
40 computing environment according to one embodiment; 
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Figuje 21 is an illustration of a Space event type hierarchy for one embod 

Figure 22 is a flow diagram illustrating service instantiation in a distributed computmg environment 
according to one embodiment; 

Figure 23 is an illustration of a defeult space in a distributed computing environment according to one 

5 embodiment; 

Figure 24 iUustrates an example of a device brid^g proximity-based devices onto another transport 
mechanism to allow the services provided by the proximity-based devices to be accessed by devices outside the 
proximity range ofthe devices, according to one embodiment 

Figure 25 is an illustration of the use of lease renewal messages in a distributed computmg environment 

10 according to one embodiment; 

Figure 26a is a flow diagram iUustrating an authentication service providm^ 

a client according to one embodiment; 

Figure 26b is a flow diagram expanding on step 1002 of Figure 26a and illustrating an autiientication 
service generating an authentication credential according to one embodiment; 
15 Figure 27 illustrates one embodiment ofa bridging mechanism; 

Figure 28 illustrates an example of a space discovery protocol mapped to an external discovery service 

according to one embodiment; 

Figure 29 Illustrates bridging a client external to tiie distributed computing environment to a space in die 
distributed computing envhronment according to one embodiment, 
20 Figure 30 is an iUustration of a proxy mechanism according to one embodiment 

Figure31 iUustiates one embodiment of a client with an associated display and display service acw^ 

one embodiment; 

Figwes 32A and 32B illustrate examples of using schemas of dynamic display objects according to one 
. embodiment; 

25 Figure 33 A illustrates a typical string representation in the C progranaming language; 

Figure 33B illustrates an exanq>le of a conventional string function; 

Figure 33C illustrates an efficient method for representing and managing strings in general, and in smaU 
foo^rint systems such as embedded systems m particular according to one embo^^ 

Figure 34 illustrates a process of moving objects between a client and a service according to one 
30 embodiment; 

Figures 35a and 35b are data flow diagrams illustrating embodiments where a virt^ 
includes extensions for compOmg objects (e.g. Java Objects) into XML representations of the objects, and for 
decompiling XML representations of (Java) objects into (Java) objects; 

Figure 36 iUustrates a client and a service accessing store mechanisms m the distributed computing 
35 environment, according to one embodiment; 

Figure37 iUustrates process migration using an XML representation of the 

one embodiment; * . 

Figure 38 iUustrates a mobUe cUent device accessing spaces in a local distributed computing network, 
according to one embodiment; 
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Figure 39a illustrates a user of a mobfle device discovering the location of docking stations, according to 
one embodiment; 

Figure 39b illustrates a mobile client device connecting to a docking station, according to one embodiment; 

Figure 40a Ulustrates an embodiment of embedded devices controlled by a control system and accessible 
5 wito the distributed computing environment, according to one embodiment; 

Figure 40b illustrates a device control system connected via a network (e.g. the Internet) to embedded 
devices accessible within the distributed computii^ environment, accorto^ 

Figure 41 is a flow chart illustrating service discoveiy according to one embodiment; 

Figure 42 is a flow chart iUustratmg an example of locating service advertisements according to one 
10 embodiment; 

Figure 43 is an illustration compares the difference in the discover process when the published 
advertisement is a complete advertisement versus a protected advertisement, according to one embodiment; 

Figure 44 is a block diagram of an example of a system in which a client device directly discovers a service 
on a service device over a proximity link, according to one embodiment; and . 
15 Figure 45 is a basic flow diagram aiustratmg cUent discoveiy of a proximity service, accordnig to one 

embodiment 

While the invention is susceptible to v^ous modifications and alternative forms, specific embodnnents 
tiiereof are shown by way of example in the drawings and will herein be described in detml. It should be 
understood, however, that the drawings and detailed description thereto are not mtended to limit the mvention to tiie 
20 particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives 
falling within the spirit and scope of the present invention. 

I3ETAI1LEP DESCRIFnON OF EMBODIMENTS OF THE INVENTION 

25 Overview of Embodiments for Distributed Computmg 

Turamg now to Figure 2, a distributed computing environment programming model is illustrated, Tte 
model includes API layer 102 for feciUtating distributed computing. The API layer 102 provides an interfece that 
facilitates cHents connecting to services, ite API layer 102 is concerned with the discovery of and the connecting 
of cUents and services. The API layer 102 provides send message and receive message capabi^^^ 
30 API may provide an interface for simple messages m a representation data or meta-date format, such as in the 
extensible Mark-up Language (XML). Note that while embodiments are described herein employing XML, other 
meta^ta type languages or foimats may be used in aheraate embodiments. In some embodiments, the API layer 
also provide an interface for messages to communicate between objects or pass objects, such as Java objects. 
API's m^ be provided to discover an object repository or *^space^ find a particular oy 
35 object, and write or take an object to or from the object repository. Objects accessible through API layer 102 may 
be represented by a representation data format, such as XML. Thus, an XML representation of an object may be 
nianq)ulated, as opposed to tiie object itself. 

API layer 102 sits on top of a messagmg layer 104. The messa^g layer 104 is based on a representation 
- data format, such as XML. In one embodiment, XML messages are generated by messaging layer 104 according to 
40 calls to the API layer 102. Hie messa^g layer 104 may provide defined static messages that may be sent between 
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clients and services. Messaging layer 104 may also provide for dynamicaHy generated messages. In one 
embodiment, an object, such , as a Java object, may be dynamically converted into an XML representation. The 
messaging layer 104 may then send the XML object representation as a message. Conversely, the messaging layer 
104 may receive an XML representation of an object The object may then be reconstituted from that message. 
5 In one embodiment, messages sent by messaging layer 104 may include several basic elements, such as an 

address, authentication credentials, security tokens, and a message body. Tlie message system transmission and 
receive mechanisms may be completely stateless. Any notion of state may be embedded in the message stream 
between sender and receiver. Thus, mwsage transmission may be done asynchronously. In a preferred 
embodiment, no com>ection model is imposed Itus. transports such as TCP are not required. Also, error 
10 conditiors may be limited to non-delivery or security exceptions. 

Messaging layer 104 sits on top of a message capable networking layer 106. In a prefsrred embodiment; 
messaging l^er 104 does not require lluit a particular networking iffotocol be used. TCP/IP and TO^ 
examples of mess^e capable protocols that may be used for message capable networking layer 106. However, 
other more specialized protocols such as the Wireless Application Protocol (WAP) may also be used. Other 
15 possible message protocols are IrDA and Bluetooth networic drivers beneath flie transport layer. Netwoiking layer 
106 is not limited to a single reliable connection protocol, such as TCP/IP. Therefore, connection to a larger variety 
of devices is possible. 

In one embodiment, message capable network layer 106 may be implemented from the networking classes 
provided by the Java2 Micro Edition (J2ME) platform. Hiie Java2 Micro Edition platform may be suitable for 
20 smaUer footprint devices (bat do not have the resources for a foil Java platform or in which it would not be efBcient 
to run a full Java platform. Since J2ME already provides a message capable fenrily of netwoiking protocols (to 
support, sockets), it follows that for fte small foo^t cost of adding messaging layer 104, distributing conq)uting 
fedlities may be provided for small devices that already include J2ME. 

Message capable networkmg layer 106 may also be provided by the Java Development Kit's (JDK) 
25 javajiet networking classes. Altematively, any message capable networkmg feciMes may be used for message 
capable networking layer 106. In a preferred embodiment, a reliable transport is not required, tiius embedded 
devices supporting an unreUable data gram transport such as UDP/IP may still support llje messag^ng layer: 

Thus, thin clients may participate in a cUstributed computing environment by simply adding a thm 
messaging layer 104 above a basic networking protocol stack. As shovm in Figure 3. a basic system includes 
30 messa^g l^er 104 on top of a networidng layer 106. The netwoiking layer may provide for reUable messages. 
. e.g. TCP. or unreliable messages, e.g. TOP. The Intanet Protocol (IP) is shown in Figure 3 as exainple of 
protocol ftat may be used in networking layer 106. . However, the distributed computing environment does not 
require IP. Other protocols may be used in flie dfetributed conq>uting oivironment besides IP. A network driver 
such as for Ethernet, Token Ring. Bluetooth, etc. may also be part of the networking layer. Many smaU cUents 
35 already provide a network driver and transport protocol such as UDP/EP. Tim, with ttie addition of tiib thin XML 
based messaging layer, the device may participate in the distributed computing oiwonment 

Thus, the foundation for the distributed computing environment is a simple message passmg layer 
in?)lemented on top of reUable connection and/or unreliable data grams. The messaging technology is very different 
fiom communications tedmologies employed in other distribution computing systems, such as Jini vAach employs 
40 the Java remote method invocation . (RMI). The message passing layer 104 supports an asynchronous, stateless style 
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of distributed programming, instead of the synchronous, state^fiill style predicated by RML Moreover, message 
passing layer 104 is based on a data representation language such as XML and thus copies data, but not code, from 
source to destination, unlike RMI. By using a representation data language, such as XML, messaging layer 104 may 
interoperate with non-Java and non-Jini platforms m a seamless feshion because Java code is not assumed on the 
5 sending or receiving end of a message. Moreover, unlike RMI, messaging layer 104 does not require a reliable 

transport mechanism such as TCP/IP. 

The message passing layer may provide simple sendO and receiveO methods to send a m 

an array or string of bytes, for example. The sendQ method may return immediately, performing the data transfer 
asynchronously. For flow control purposes a callback method may be supplied which is invoked in the event that 
10 the sendOmediod throws an exception indicating it cannot handle the sendO 
synchronous and may return the next available message. 

The message passmg layer may also provide methods for storing XML repr^ntations of objects, services 
and content in "spaces". A space is named and accessed on the network using an URI (Uniform Resource 
Identifier). The URI may be a URL (Uniform Resource Locator) or a snnpler version of a URL. In some 
15 embodiments, the URL class may be too large. For such embodiments a simpler resource locator may be used that 
specifies the protocol for moving the messages between client and server, protocol dependent host ID, protocol 
dependent port ID, and a space name. 

An XML representation of an object may be added to a space using a writeQ method provided by the 
messaging layer. In one embodiment, the object and the client-specified name may be suppUed as. parameters. In 
20 bne embodiment, the write method may translate the object mto its XML representation. A takeQ method may be 
provided to return the object and remove it from the space. A findQ method may be provided to return a specified 
object from its XML representation m a space. The findQ method may also be used to return an array of thatching 
objects in a space given a class. Each of these space methods is implemented usmg the message-passing layer. A 
leasemechanism may also be provided, as described in more detail below. 
25 A discovery service may be provided for clients as a general search fecility that may be used by a client to 

locate a particular space. Rather than attempt to define a complicated search prot;ocol which may not be feasible for 
a thm cUent to implement, the discovery service may offload the actual search to XML-based search fecilities, 
leaving the discovery service sunply to provide interfece fimctionaUty to the client The ^proach is iUustrated m 
Figure 4. In one einbodnnent, the discovery service receives a string specifying something to locate, and it sends an 
30 XML message to a known discovery front-end (perhaps found in a defeult space), which then parses the string and 
makes a conespondmg XML query to a search facility (which may be an mtemet search fecUity). The discovery 
front-end may parse vdiat it obtains from die search fecihty and repack^e it as aa array of strings (each string may 
be a URI for each found space) wMch it may send m an XML message to the client It should be noted that the 
discovery service does not require that the messagnig be atop a comiection-oriented transport. Thus, even very Ihin 
35 cUents that do not have TCP could use such a discovery service. The discovery fix)nt-end makes it possible for the 
cUent to discover spaces without a browser or search feciUty on the cUent The cUent only needs a shnple facility 
. that sends a string that specifies keywords to the front-end, wiiich interfeces widi a search facility. 

A client rnay be any platform that can send a message usmg at least a subset of the API and messaging 
layers. In one embodiment the API layer may provide for both static (or raw) and fonhatted (or cooked) messages. 
40 A server may be any platform capable of receiving and falfiUing message requests. An e5q)HcH raw message send 

13 . 



wo 01/86394 



PCTAJS0iyi5134 



may be provided that moves a series of bytes from a client to a server or to another clieat The message type may be 
specified as reliable (e.g. TCP) or unreliable (e.g. UDP). The smallest of devices may use raw unreUable message 
passing as their sole means of participation in the distributed computing enviromnent The device may use these 
messages to announce its presence and its status. Such small devices may also receive raw messages to implement 
5 certain functions, such as turning a feature on or offl 

Message-based services such as. spaces may send and receive i-eliable formatted messages; A space 
message may be formatted with a well-defined header and with XML. In one embodhnent, a formatted message 
send may occur when a client uses a space method to claim, write, or take objects fi-om a space. The message 
contents m^ be dynamically formatted in XML and contmnweU-defined headers. . 
10 supporting formatted and static messages. By using static messages, smaU devices may use a smaller proffle of code 
to participate in the distributed computing environment For example, a small device could just send basic 
pre-defined messages. Depending on tiie client the static pre-defined messages may consume a small amount of 
memory (e,g. <200 bytes). Static messages may also be an option even for larger devices. On the otiier hand, the 
dyiiainic XML messages may be useftd when object values are not known at compile time. 
15 Turning now to Figure 6, a distributed computing model is illustrated that combines a messagmg system 

vdtii XML messages and XML object representation. The platform independence of XML may be leveraged so tiiat 
the system may provide for a heterogeneous distributed computing environment Thus, client 110 may be 
implemented on ahnost any platform instead of a particular platform like Java, The messaging system may be 
implemented on any networic capable messaging layer, such as Intemet protocols (e.g. TCP/IP or UDP/IP). Thus, 
20 the computing environment may be distributed over the Internet la one embodiment, the messagmg system may 
also use shared memory as a quick interprocess message passmg mechanism when the client and/or space servOT 
and/or service are on tiie s^e computer system. The distributed computing model of Figure 6 m^ also be very 
scalable because ahnost any size cHent can be configured to send and/or receive XML mess^^ 

As shown in Figure 6, two kinds of software programs may run in tiie distributed computing model: 
25 services 1 12 and clients 110. Services 1 12 msy advertise their c^abilities to clients wishing to use the service. The 
services 112 may advertise tiieir capabilities in spaces 1 14. As illustrated in Figure 7, clients 1 10 and services 1 12 
may or may not reside within the same networic device. For example, devices 120 and 124 each support one client, 
whereas service 1 12a and cUent 1 10b are inq>lemented in die same device 122. Also, as illustrated in Figure 7, no 
particular platform is requked for the devices to support tiie cUents and services. For example, device 120 is Java 
30 based, whereas device 124 provides a native code runtime environment 

A device may be a networking transport addressable unit Example devices include, but by no means are 
limited to: PDAs, cellular/mobile phones, notebook computers, laptops, desktop computers, more powerfiil 
computer systems, even supercon^uters. Botii clients and services m^ be URI-addressable instances of softvrare 
(or firmware) that run on devices. Usmg the distributed computing environment architecture, a client may run a 
35 service. A space is a service tiiat manages a repository of XML documents. Even though it is redundant, tiie torn, 
^ace service, may be used herein, for readability. A software component may be botii a client and service at 
diflferent times. For example, when a service uses a space (e.g. to advertise itself), tiiat service is a client of tiie 



Figure 8 illustrates tiie basic model of tiie distributed computing environment m one embodiment The 
40 distributed computing environment may connect cUents 1 10 to services 1 12 tiiroughout a network. The networic 
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may be a wide area network such as the Internet The network may also be a combination of networks such as a 
local area netwoik (LAN) connected to a wireless network over the Internet As shown in Figure 8, a service 112 
publishes an advertisement 132 for itself(represented in XML) in a space 114. The advertisement 132 specifies the 
service's XML schema and URI address. Then, a cUent 1 10 may look up the advertisement 132. The client 110 

5 may use the advertisement 132 to mstantiate a gate 130: The gate 130 allows the cUent 1 10 to run the service 1 12, 
by sending (and receiving) XML messages to (and from) the service 112. 

Some results of runnmg a service may be returned to the client m an XML message. However, since other 
results may be too large for a small client to receive and consume at once, a service 1 12 may put those results or an 
XML representation of the results 134 in a space 114. as shovra m Figure 9, and return them by reference (m an 

10 XML message) to the client 1 10, rather than by vahie. Examlples of methods of returning a reference to results 
inchide,butarenotlinutedto:retiirnkgintheniessageaURIre^ 

message an XML document including the URI of the results. Later, the client 110 may access the results, or pass 
them by reference to anotiier service. The space m li^ch results naay be stored may be different firom the space in 

which the service is advertised. 
15 In one embodiment, the distributed computing envirorment uses XML for content definition, advertisement 

and description. New content for the distributed computing environment (messages and advertisements for 
example) are defined in XML. Existing content types (e.g. developed for other environments) may also be 
described using XML as a level of indhection (meta-data). XML provides a powerful means of representing data 
throughput a distributed system because, similar to the way that Jav^ provides universal code, XML provides 
20 universal data. XML is language agnostic and is self-describing. The XML content may be strongly ^yped and 
validated usmg schemas. Using a provided XML schema, the system may ensure that only valid XML content is 
passed in a message. XML content may also be translated, into other content types such as HTML and WML, 
Thus, cUents that do not understand XML may still use the distributed computi^ 

In one embodiment, the distributed computing envirrament messages may define the protocol used to 
25 connect clients with services, and to address content in spaces and stores. The use of messages to define a protocol 
allows many different kinds of devices to participate in the protocoL Each device may be free to impleinent the 
protocol in a manner best suited to its abiUties and role. For example, riot all devices are capable of supporting a 
Java runtune environment The distributed computing environment protocol definition does not require nor imply 
the use of Java on a device. Nor does it preclude it 
30 A service's capabilities may be expressed in terms of ttle messages the service accepts. A service's message 

set may be defimed using an XML schema. An XML message schema defines each message format using XML 
typedtags. TTie tag usage rules may also be defined in the stiema. The message schema may be a comi^^ 
XML advertisement along widi the service's message endpoint used to receive messages. ITie disbibuted computing 
environment may allow clients to use ail or some subset of a service's capabihties. Security policies may be 
35 employed to enforce the set ofcapabilities given to a client For example, once a set of capabilities has been given 
tb a client, the client may not change that set without proper authorization. This model of capability definition 
allows for services levels that range from a base set of capabilities to an extended set Extensions may be added to 
services by adding to the number of recogoizied messages. 
- ' In one embodfanent, all operations in the distributed con^utmg environment are embodied as XML 
40 messages sent betweai clients and services. Storage (both transient and persistent) providers are exanq)les of 
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services that enable clients and services to store, advertise, and address content Clients and services may find each 
other and broker content using a transient storage space. Services may place a content or service advertisement in a . 
space. The advertisement may describe the content type or the capabilities of the service. Cliisnts may subsequently 
browse spaces looking for advertisements that match a desired set of capabilities. When a client finds a matching 
5 advertisement, a communication channel may be established which may enable bi-direc 

service backing the advertisement. In one embodnnent, the communication channel is au&enticated. Resulte (which 
are just another content type) from service operations may be returned du-ectly to the client in a response message, 
advertised and stored in a space, or advertised m a space, but stored persistently. Stored results may be addressed 
using a URI (e.g. returned in the response message) and may have an associated authentication credential 

10 

Message Gates 

As discussed above, the distributed computing environment leverages off the use of a data description 
language, such as XML. XML may be used to describe a target entity (e.g. document, service, or client) to an extent 
such Aat code may be generated to access that entity. The generated code for accessinjg the target entity may be 
15 referred to as a message gate. Thus, in one embodiment, the distributed computing environment differs fix)m other 
distributed computing environments in that instead of passing the necessary code between objects necessary to 
access the other object, the environment provides access to XML descrq)tions of an object or target so that code 
may be generated based on the XML description to access the target The distributed computing environment mzy 
use an XML schema to ensure type safety as well as a programming model (e.g. siq)ported messages) without having 
20 to agree upon language specific APIs, just XML schemas. 

Code generated fi-om an XML schema may also incorporate the language, security, ^pe safety, and 
execution environment characteristics of the local platform. The local platform may thus have control over the 
generated code to ensure that it is bug-free and produces only valid data according to the schema. The generated 
code may conform to the client's code execution envkonment (e.g. Java, C-H-, Smalltalk), as well as its management 
25 and security frameworic (W eb-server and/oi* operating system). 

Note that the distributed computing environment does not require that code generated from an XML 
schema be generated "on the fly" at runtime. Instead, some or all of the code m^ be pre-generated for categories 
(or classes) of services, and then hnked-m during the platform build process. Pre-generation of code may be usefijl 
for some clients, such as embedded devices, where certain XML schemas are aheady known. In one embodiment, 
30 some or all of the code doesnt actually have to be generated at alL A private code-loading scheme (within the 
client) might be used m one embodnnent to augment the generation process. In addition, the distributed computing 
environment msy specify, in some embodnnents, an interface to download code for additional features in accessing 
a service (see, e.g^ message conductors described below). Typicalfy, such downloaded code be small and the 
client may have the option to download the code or not 
35 Hie phrase "generated code** may refer to code that origmates within the client under the control of tiie 

client code execution envfronment, or to code that is generated elsewhere (such as on the service system or on a 
space service system) and that may be downloaded to the client system after generation. Binding time, however, 
may be at runtime. At runtime, the generated code nmy be bound to a service address (UlUO^sb that a message 
be sent to that service instance. 
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As discussed above, the interface to any service in the distributed computing environment may be specified 
by an XML schema, defining the set of messages that a client may send (and receive fioin) that service. As 
illustrated in Figure 10, the client 1 10 and service 1 12 may each construct a message gate 130 for communicating 
according to the specified XML schema; From the XML schema advertised for the service 1 12 (and possibly other 
information in the service advertisement), a message gate 130a or 130b may be constructed by the client 110a or 
110b respectively. A corresponding message gate 130c generated from the same XML schema may also exist on the 
service 112a. A gate 130 is a message endpoint that may send and/or receive type-safe XML messages, and that 
m^ verify the type correctness of XML messages virhen sending and/or receiving the messages. The meissage gate 
may also provide for authentication and/or other security mechanisms to ensure that the message endpoint is secure. 
In one embodiment, message gates are always secure. 

The distributed computing environment messaging layer described above may be coupled to or may be part 
of ttie gate. The messaging layer asynchronously delivers an ordered sequence of bytes, using a networkmg 
transport, from the sender to the receiver, inaint^ning the notion on both the sender and receiver that this sequence 
of bytes is one atomic unit, the message. The distributed computing environment does not assume that tiie 
networking transport is IP-based. Instead, the messaging layer may sit atop whatever networking transport layer is 
supported by the device. 

Message gates may provide a mechanism to send and receive XML messages between clients and services. 
The XML messages may be "typed*'. For example, the messages may include tags to indicate if a message data field 
is, e.g., integer, floating point, text data, etc. A message gate may be constructed to verify the type correctness of 
messages sent or received. A message gate also may authenticate (e.g. securely identify) the sender of a received 
message. An XML schema may be provided for a service that describes the set of messages accepted by the service 
. and/or sent by the service. A message gate may verify the correctness of messages sent or received according to the 
XML schema for vsiiich the gate is constructed. 

A gate may be constructed as a single atomic unit of code and data that perforins type verification and/or 
message conectness verification and/or sender identification for messages between a cHent and a service in the 
distributed computing envhonment In one embodiment, once the atomic tinit of code and data for a message gate 
has been created, it cannot be altered as to its typing, message descriptors, and sender identification. In another 
embodiment, the gate may be modified as to the contents of the message schema after the gate is created, including 
deleting^ adding, or modifying messages in the message schema. 

A message gate is the message endpoint for a client or service in the distributed computing environment A 
message gate may provide a secure message endpomt that sends and receives type-safe XML messages. Messages 
gates m^ allow clients and services to exchange XML messages in a secure and reliable feshion over any suitable 
message transport (e.g. HTTP). For a client, a message gate may represent the authority to use some or all of a 
service's capabilities. Each capability may be expressed m terms of a message that may be sent to a service. Each 
such message may be sent through a client message gate which may verify the correctness of the message. The 
message may be received by a service message gate which may authenticate the message and verifyr its correctness. 

A message gate may provide a secure communication endpoint that type checks XML messages. As 
further discussed below, a message gate may ialso provide a mechanism to restrict the message flow between clients 
and services. In one embodiment vfhen a client desires to access a service, a client and service message gate pair is 
created, if not already existing. In one embodiment, the service message gate may be created when the service 
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receives a first message from the cUent message gate. In one embodiment, one or more service m^sage gates may 
be created when the service is initialized, and may be used to pair with client message gates when created. The 
creation of a message gate may involve an authentication service that may negotiate the desired level of security and 
the set of messages that may be passed between client and service. In one embodiment, the authentication service 

5 may accept a client ID token (also referred to as a cUent token), a service ID token (also referred to as a service 
token), and a data representation language message schema tiiat describes the set of data representation language 
messages that may be sent to or received from the service. For example, messages may be described that may be 
sent from a client to a service to invoke the service or to invoke aspects of the service. Messages may ako be 
described that are to be sent from the service, such as response messages and event notification messages. Refer to 

10 the Authentication and Security section below for a finlher discussion of h^^ 

in the construction and use of message gates. 

A client message gate and a service message gate pair may aUow messages to be sent between th^ 

and the service. In one embbdhnent, message gates may be created that only send and/or receive a subset of the 
total set of messages as described in the message schema for a service. This limited access may be used withhx the 
15 distributed computing environment to implement a policy of least privilege whereby clients are only given access to 
specific individual message types, based on a security policy. Refer to the Authentication and Security section 
below for a further discussion of security checks for gate usage and gate creation. 

Client and service gates may perform the actual sendmg (and receiving) of the messages from the client to 
the service, using the protocol specified in the service advertisement (URI of service in the service advertisement). 
20 The client may run the service via this message passing. A message gate may provide a level of abstraction between 
a client and a service. A client may access a service object throu^ a message gate mstead of accessing the service 
object directly. Since the gate abstracts tiie service fix)m the cUent, the service's code may not need to 
and then started, until the client first uses the service. 

The client gate may also perform verification of tiie message against the XML schema, or verification of 
25 the message against the XML schema may be performed by the service gate, e.g. if the cUent indicates it has not yet 
been verified. In some embodiments, verification may not be practical for simple clients and may thus not be 
required at the cUent In some embodiments, verification may be performed by the service. The gates may also 
perform authentication enablement and/or security schemes, hi one embodiment, if a client does not support tiie 
protocol specified in the service advertisement, then it may not be able to construct the right gate. To avoid this 
30 problem, service advertisements (used for gate construction) may include a Ust of possible URIs for a service, so a 
variety of clients may be supported. 

A basic message gate may implement an API to send and receive messages. The API moves date (e.g. 
XML messages) in and out of tiie gate, vaUdating messages before sending and/ or upon receiying. In one 
embodiment, inessage gates m^ supfK)rt a fixed niii^ HusAPImaybe 
35 extended to other features as discussed below. As ilhistrated in Figure 10b, a gate 130 may be genorated according 
to an XML schema 132. The generated gate code verifies messages based upon tiie XML schema. Ihe giate may 
verify conect message types and/or content tiffough the message API. As illustrated m Figure 10b, througji the 
message API a verified message may be sent to a service. TTie message may be received by a coirespondmg gate at 
• the service. In response to fee message, the service' may generate results 180. Tlie service may return result data 
40 182 through its gate. Ihe results data may be the results themselves or a reference to the results, such as a URI to 
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results stored in a space.. In various embodiments, the message API may support synchronous messages (request- 
response), asynchronous messages (response is disconnected from request), unicast messages (pomt to point), multi- 
cast messages (broadcast), and publish and subscribe (event messages), for example. Other type of messages may 
also be supported, such as remote method invocation messages. 

5 Each message sent by a gate may include an authentication credential so that the receiving gate may 

authenticate the message, Each message may also include a token which ihchides information aUowing the 
receiving gate to verify that the message has not been compromised or altered. For example, the sender may 
compute a hash or checksum of the message which may be verified by the receiver. The sender may also encrypt 
this token and/or the entire message usmg the sender's private key and may mclude in encrypted message the 

10 corresponding pubUc key so that the receiver may verify th^ the token was not changed See the section below on 

Authentication and Security. 

A pair of message gates m^ provide a mechanism for communicatmg requests from cUents to servi 

response from services to cHents. Two associated message gate endpoints may be used to create a secure atomic bi- 
directional message channel for request-response message passing. Hius, the distributed computmg environment 
15 may employ a message transport in which a message gate exists on both the client and the service sides. Hie two 
gates may work together to provide a secure and reliable message channeL 

Turning now to Figure 1 la, an illustration is provided for one embodiment showing construction of a gate 
130a in a cHent 110 from a service advertisement or other service description 132. The client may have a gate 
fectory 140 tibat is trusted code on the client for generating gates based on XML service descriptions. The use of the 
20 gate factory 140 may ensure that the gate it generates is also trusted code, and that tiie code is correct with re^^ 

the service advertisement As shown in Figure 1 lb, a gate I30c may also be constructed at a service 1 12. The cUent 
gate 130a and the service gate 130c provide message endpoints for communications between the cHent and sendee. 
In one embodiment, the pieces the gate fectory needs to construct a gate 130 are the XML schema of the service 
(from the service advertisement) and the URI of tiie service (from the service advertisement). In another 
25 embodiment, an authentication credential may also be obtaiiied and used in gate construction by rumiing an 
authentication service specified in the service advertisement 

A gate factory may provide a trusted mechanism to create message gates. In some embodnnents, in order 
to ensure that a message gate is a trusted message endpoint, the code used to create the gate must be trusted code. A 
gate fectoiy 140 may be a trusted package of code tiiat is used to create gates. In one embodiment, each client and 
30 service device platform that desires to send and receive messages in the distributed computing environment may 
have a gate factory. Iii some embodiments, gates may be pre-coiistructed by a separ^ 

witii pre-constructed gates may not need a fuU gate fectory, or may include a partial gate fectory for binding a 
service XJRI and/or an authentication crwiential to tiie pre-constructed gate at runtime (e.g. when messagmg is 
desired). 

35 A gate fectory for a device may generate gate code tiiat may incorporate die language, security, type safety, 

and/or execution enviromnent<^aracteristicsbfthe local device pl^^ By constructing gates itself a device has 
tiie abitity to ensure that tiie generated gate code is bug-free, produces only valid data, and provides type-safety. An 
advantage of a device generating its own gate code as opposed to downloading code for accessing a service is tiiat 
' the cUent code management environment has tiie control. The generated code may conform to tiie client's code 

40 execution environment (e.g. Java, C++, SmaUtalk), as well as its management and security framework (Web-server 
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and/or operating system). Generated code is also trusted code, because the clienfs nmtime environment was 
involved in its creation. Trusted security infonriation therefore may also be added by the trusted generated code. 
Thus, a device may receive an XML message schema for a service and then construct a gate based on that schema to 
access die device. The XML schema may be viewed as defining the contract with the service and the generated gate 
5 code as providing a secure way to execute the contract Note that open devices, in which un-trusted (e.gi 
downloaded) code may be run, may be configured so that gates may be generated only by trusted code. Open 
devices may employ a process model in which gates are enclosed in a protected, isolated code container that is not 
accessible to toob> such as debuggers, capable of discovering the gate's implementation, especially the gates 
authentication credential. 

10 A gate factory 140 may negotiate on behalf of a client with a service to create a gate to send messages to 

the service. Similarly, a gate may be constructed at the service to receive messages firom the client gate and send 
messages to the client gate. Together, the client and service gates may form a secure bi-directional communication 
channel. 

A gate fectoxy may provide a level of abstraction in gate creation. For example, yAicn a client desires to 
15 use a service, instead of the cUent directly creating a gate to access tiie service, fee gate may be created by a gate 
factory as part of instantiating the service. 

The gate fectory may create or may include its own trusted message gate that is used to communicate with 
an authentication service (e.g. specified by a service advertisement) to receive an authentication credential for the 
gate beiag constructed. For services that do not restrict access, a gate may be constructed without an authentication 
20 credential. The gates for such services may not need to send an authentication credential with each message smce 
the service does not restrict access. The authentication service is an example of a service that does not restrict 
access, in one embodiment Thus, a gate fectory may be configured to optumze .gate construction by checkmg 
whether a service restricts access. If the service does not restrict access, then the gate fectory may avoid running an 
authentication service as part of gate construction and may avoid mcluded provisions for an authentication 
25 credential as part of the constructed gate, the gate factory may also receive or download an XML message schema 
(e.g. specified by a swvice advertisement) to create a gate matching that schema. The gate factory may also 
receive or download a URI for the service and/or for a service message gate for use in creating the client message 
gate to communicate with the URI. . 

In addition, ano&er gate construction optimization may be employed for certain clients that do not desbre to 
30 perform checkirig of messages against a service's XML schema. The client may be too thin to perform the checking 
or may rely on the sendee gate to perform the checkmg or may simply choose not to perform the checking (e.g. to 
reduce gate memory footprint). The gate fectory may be configured to receive an indication of whetho: or not a ^ 
should be constructed to verify messages against the provided XML schema. In some embodiments, certain clients 
may have a gate fectory that does not provide for message verification agamst a schema for rts constructed gates. In 
35 some embodiments, gates may be pre-constructed not to verify messages. In some emboduncnts, a gate may be 
constructed to verify outgomg messages only, or verify received messages only. Thus, in some embodiments, a 
cUent may avoid or may chose to avoid building some or all of the gate code tiiat checks the messages against the 
XML schema. • 

In -some embodiments, devices may maintain a cache of gates to avoid constructing them each time tiie 
40 same service is run. For example, when a new gate is constructed by a gate fectory, the gate may be maintained in a 
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gate cache. When the gate is no longer bemg used, h is kept in the gate cache instead of being deleted. If the gate 
cache becomes foil, one or more gates may be removed from the gate cache according to a cache replacement 
algorithm, such as least recently used. When the gate factory is called to construct a gate, it first checks the gate 
cache to see if a matching gate already exists so that construction of anew gatemay be avoided, 
5 The building of a gate may be made Ughtweight by appropriate reuse of pieces used to construct other 

gates. Certam portions of each gate may be the same, and thus may be reused from gate to gate, such as parts of the 
message verification code. Also, for some devices, common gate code may bebuilt into the system software for the 
device and shared by all gates on that device. Thus, the gate fectoiy may avoid rebufldmg this common code for 
each gate, histead, the gate fectory may simply bind the gate to this system software portion. For example, a system 
10 sofhvare portion may be provided to handle the message l^er over \^tevCT transports a^^ 

Space services in particular may be good candidates for many of the gate constniction optimizations 
described above since a service gate constnicted for a space service may perform many of the same functions as 
other service gates for that space service. Refer to the Spaces section below for more iiiformation on space services. 
In some instances, a more efiBcient form of meihod invocation may exist For example, if tiie target service 
15 runs m the same Java Virtual Machine as the client application, a more efficient form of metiiod invocation may be 
to create a Java dynamic proxy class for the service. In such a case, a javallang jreflect Metiiod invocation may be 
faster tiian sendmg a message. A gate binding time procedure may check for such an optimization and use it instead 
of running tiie gate factoiy to create a gate or bind an existing gate. 

In one embodiment, such as for special-purpose clients or small embedded devices, the generation of gate 
20 code at runtime may not be desirable due to memory consumption and code generation tune. Thas, instead of 
having a gate factory fhat generates gates at runtime, in some embodfanents gates may be pre-generated and built 
into tiie device. For example, message gates may be generated during tiie build of embedded software as a meam of 
including a buUt-in secure message endpoint tiiat does not have to be constructed at runtime. Thus, a client witii 
built-in gates may not need a fuD gate factory, or m^ require only a partial gate fectory for performmg certam 
25 runtune binding to a built-in gate, such as for the Uia and/or authentication credentid^ 

A generation tool may be provided for the pre-construction of gates. The generation tool inay include an 
. XML parser, a code generator and a code compiler. In one embodiment, tiie code generator may be a Java source 
code generator and tiie code comptter may be a Java code conq>Uer. During the build of the software for which 
built-in message gates is desired, the generation tool is run witii ttyput fiom aU die relevant XML schemas for vM^ 

30 gates are desired. 

As an example, if it is desired for a device to have a buflt-in message gate that 

messages from a di^ camera, tiie build of the device software may inchide running tiie gate gener^ 

. tiie camera's XML message sdiema as input The XML schema may be parsed by tiie XML parser tiiat m^ convert 

tiie XML schema into an mtemal form suitable for quick access during a message verification process. . The tool's 

35 . code generator may provide source code for a gate corresponding to tiie camera's schema. In some embodiments, 
tiie generation tool may also compae tiie source code and tiie gate code may be linked into the software package for 
the device. At runtime, tiie camera service may be discovered in tiie distributed computing environment The 
message URI for tiie camera service may be bound to tiie built-in gate for tiie camera witiiin the device, the bindmg 
of the tJRI to tiie pre-constnicted gate may be performed by a gate constructor witiiin tiie device. This gate 

40 constructor inay be a much smaller, simpler gate fectory. When tiie cam^a service is instantiate^ the URI for. the 
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camera service is passed to the gate constructor as an XML message. The gate constructor may then bmd the URI to 
the pre-constnicted gate. 

Tlius, a gate may be partiaUy or My generated at runtime, or a gate may be pre-generated before runtime 
with a bbding process (e.g. for a URI or credential) performed at runtime. In one embodiment, a gate generation 
5 tool such as the gate factory or the generation tool for pre-constnicted gates ma/ be a Java-based tool to provide 
some level of platform independence. Alternatively, gate generation tools may be provided m any language, such as 
the native code for a particular device in the distnTjTited computing environme^^ 

Note that the distributed computing environment does not preclude a device from downloadmg part or aU 
of a gate's code. For example, in some embodiments, a service may provide gate code that may be downloaded by a 
10 client wishing to access that service. However, dovraloaded code may present si2e. security and/or safety risks. 

A more detailed illustration of possible gate components for one embodiment is shown in Figure 12. A 
gate may inchide its address (or name) 150, a destination gate address 152, a valid XML schema (or internal form 
thereof) 154, and a transport URI 153. In otiier embodiments, a gate may also include an autiientication o-edential 
156. Some gates may also include a lease 158 and/or a message conductor 160 to verify m^sage ordering. 
15 A gate's name 150 may be a unique ED tiiat will (for the life of the gate) refer only to it A gate m^ be 

addressed using its gate name 150. In one embodiment, gate names may be generated as a combination of a string 
from an XML schema (e.g. from a service advertisement) and a random number, such as a 128-bit random number. 
The name 150 may allow clients and services to noigrate about the network and still work together. M a preferred 
embodiment, the gate address is independent ofthe physical message transport address and/or socket 1^^ Thus, a 
20 gate name may provide a virtual message endpoint address that may be bound and un-bound to a message transport 
address. In one embodiment, a gate's name may be a Universal Unique Identifier (IKTO 
the gate, refer only to it 

A gate name may persist as long as the gate persists so that different appUcations and clients executing 
within the same device may locate and use a particular gate repeatedly.. For example, a gate m^ be created for a 
25 first client process executing witiun a device to access a service. After &e first cUent process has completed its 
activity with the service, it may release the gate. Releasing tiie gate may involve un-binding the gate from the first 
client process's message transport address (e.g. IP and/or Port address). The g^te may be stored in a gate cache or 
repository. A second client process executing witiiin the same device that desires to run tiie same service may locate 
gate by its name and use it to access the service. To use the gate, the second cUent process 
30 its message transport address, so that the message endpoint for the second cUent process is a com 
. name and the second cUcat process's transport address. In anotiier example, a cHent may receive a dynamic IP 
address (e.g. a mobile cUent). When the client's transport address changes, a gate Mme (or gate names) may be re- 
bound to tiie client's new transport address so tiiat the cUent may still access a service(s) that it previously accessed 
witiiout havmg to relocate tiie service and recreate the gate. A gate name may also be useM for process migration. 
35 A process and any associated gates may be checkpointed or saved at one node in fte disdibufed computing 
envfronment and moved to another node. The process may be restarted at the new node and the associated gates 
m^ be bound to the transport address for the new node so that the process wiU stiU ha 
services to which it had access before bemg migrated A gate may track the current location of another gate to 
which it is paired Thus a service or client may be migrated and still be accessible. For example, repHcated or load- 
40 balanced service hnplementations may be abstracted from clients of the service by tiie gate. 
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Hius, a gate name 150 provides a flexible mechanism by which to address a message, endpoint in the 
distributed computing envkonment A gate name may be used to locate and/or address a gate over a wide range, of 
networks, from a local networic to the Internet. Gate names may be independent of message transport so that a 
message endpoint (gate) may be moved jfrom transport to transport by unbinding and rebinding to different 
underlying transport addresses (e.g. IP/Port address pairs). 

. , In one embodiment, a gate may also be separated from a service so that the same gate may be used to send 
requests to different services over time. This may involve un-binding the gate's destination gate address 152 and 
binding anew destination gate address to the gate. 

A gate may be implemented as a layer above a device's transport layer {e.g. networking sockets). Each 
gate may include a transport reference 153. The gate name 150 may be bound to the transport reference 153 as 
. described above. Multiple gates may share the same message transport For example, multiple gates may have 
transport references 153 to the same TCP/IP socket By sharing the same message transport, the size and 
complexity of each gate may be reduced A device in the distributed computmg environment may have a large 
number of gates that need to send and receive messages. The message handling complexity for multiple gates may 
i be reduced by sharmg a common message transport The transport reference 153 m^ be a transport URI (e.g. 
URL) or socket reference and may provide a mechanism for naming an underlying transport and sharing the 
transport with other gates. Multiple local gates may mclude a reference 153 to the same transport, however, each 
local gate may behave mdependently of the other local gates sending and receivmg messages to and from its paired 
remote gate. 

20 Hie schema 154 may be downloaded from a space into the gate by the gate fectory. The schema may be 

compiled mto an internal form suitable for quick access during a message verification process. In one embodiment, 
tiie schemamay specify two groups of messages: client service m^ages and provider service messages. The client 
service messages group includes the description of all messages tiiat the client may send (that the provider supports), 
and tiie provider service messages group includes the description of all messages that the provider may send (that. 

25 the client receives), hi one embodiment, either the client or provider may send a particular request to the space 
service to obtain a response message with either: the entire cHent service messages, tiie entire provider service 
. messages, the entire client and provider service messages, or a specific message of either tiie cUent service messages 
or tiie provider service messages, hi addition, once a gate has been constructed, a client may query as to tiie 
capabUities of tiie service without tiie gate actuaUy sendmg a message, but instead by mspecting tiie gate's set of 

30 . messages. 

As described above, a message gate may verify tiie sender of tiie message usmg an authentication 
credential, message content for type safefy and according to an XML schema. However, it may also be deshable to 
verify that messages are sent between a cUent and a service in tiie correct order. It may be desirable to be able to 
provision appHcations (services) for clients to run witiiout any pre-existing specific fimctionalify related to tiie 
35 application on tiie client (e.g. no GUI for tiie application on tiie client). For example, a Web browser may be used 
on a cHent as tiie GUI for a service instead of requiring an appHcation-specific GUI. Of tiie possible messages m tfie 
XML schema, tiie cHent may need to know what message next to send to tiie service. It may be desirable for tiie 
cUent to be able to determine which message to send next witiiout requiring tiie cUent to have specific knowledge of 
tiie service.. In one embodiment, tiie service may continually send response messages mdicating tiie next input H 
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needs. The service would then accept only the corresponding messages from the cUait with the requested input 
specified. Oflier ad hoc scheme for message ordering may also be employed. 

In another embodiment a message conductor 160 may be employed in the gate or associated vrith the gate 
to verify the correct sequence of messages, as opposed to verifying each message's syntax (which may aheady be 
5 performed in the gate according to the schema). Message conductor 160 may provide a more general approach for 
application provisioning. The message conductor 160 may be specified in a service's advertisement Tlie message 
conductor indication in a schema may aUpw code to be generated on or downloaded to the client during gate 
construction, which may provide the choreography needed to decide which message to send next to the service. A 
message conductor may be implemented as a Java application, a Java Script. WML script, or in other programming 

10 or scripting languages. 

In one embodiment, the message conductor may accept as ii^ut an XML document (e.g. firom a service 
advertisement) that presents the valid order or choreography for messages that may be sent between a client and the 
service. This XML document may also specify user interfece information and other rules. The conductor may parse 
this XML document into an internal form and enforce message ordering (and/or other rules) according to the 

15 enclosed ordering infonnation: TTie conductor may prevent messages from being sent out of order. Or, if a message 
is sent out of order, an exception may be rais^ within the sending device. If a message is received out of order, the 
conductor may send an automatic response message back declaring the ordering eiror. The sender may then resend 
messages m the correct order. Note that m some embodiments, part or all of a conductor may be shared by several 
gates. Thus, a conductor may be linked to multiple gates. 

20 In one embodiment ofa distributed computmg environment, fiont ends for services (service interfeces) may 

be bulk in to cUents. In one embodiment, the service interfece may be a preconstructed user interfece provided to 
the client by the savice. to one embodiment, the service interfece may be provided to the cUent m the sar«ce 
advertisement The service interface may interact on the cUent with the user of the service to obtam input for 
running the service, and then may display results of running the service on the client A "user" may be a human, 
25 embedded system, another client or service, etc. In one embodiment, a cHent device may not be able to provision 
arbitrary services, as the client device may only be able to run services for which it has a ftont end built m. In one 
embodiment a service mterfece for a service may be inq)lemented ID a Web browser on the client 

In one embodiment a message conductor and/or service mterfece may be external to ttie gate and thus 
abstracted from the gate and client The abstracted message conductor may provide provisioning of ari)itrary 
30 services to any client device. In one embodiment the message conductor may be written in code fliat may run on 
substantially any platform. In one embodiment the message conductor may be written m flie Java hmguage. In one 
embodiment the message conductor may not require the arbitrary downloadmg of objects, for example. Java 
objects, returned to the cUent device. For example, very large objects may be relumed, and the message conductor 
may choose to not download these very large objects, hi one embodhnent the message conductor may send XML 
35 inessages to services from the cUent device on behalf of the client. The message conductor may interact with the 
user of the service to receive input and display results. 

to one embodiment a service mterface vasxy be provided fliat interacts with the client (e.g. thru a user 
mterfece) to obtain .all mfohnatioh to nm the service, and then may display either results of rumimg the service or 
information regardmg the location of results, as appropriate. The service mterfece may be either part of a message 
40 conductor 160 or may be in addition to and work with message conductor 160. The service interfece inay either be: 



24. 



WOOl/86394 PCT/USOl/15134 

1. Built in to the client device and thus run on tiie client 

2. Downloaded to the client device from the space server. 

3. Run on the space server. 

4. Run on the service provider. 

5 In one einbodiment. to a cUent, the distriT)uted computing environment space serv^ 

indicate if #2 is supported (by advertisement in space), indicate if at least one of #3 and #4 is supported: Note that 
•whether or not it siipports #4 depends upon wheflier or not the service provider supports #4. In one embodiment, to 
a service provider/the distributed computing environment space server must support #4 ahvays and indicate if it . 
■ siq)poTts#3. 

10 Regardless of where tiie service interface runs, once a service is activated, the service interfece may interact 

the cUent, displffymg (remotely) requests for input on the client's di^lay, and then ^ 
ofrunning the service. Su(AmtMaction with the client b implemented in terins of XML messages. 

The service interfece and/or message condurtor may meet &e needs of a client user fliat may have 
discovered a service, but does not Want to read a typically large, dry computer manual to figure out how to use the 
15 service. As the service inteifece and/or message conductor interacts with the us« to request all mput fliat the service 
needs, ftey may even provide short descriptions of the input requested if the user requests it Once Ae service 
interface has obtained the necessary information from the cUent, it may send XML messages to &e service provider 
that runs the service. The ordering of Ihe messages may be .verified by the message conductor 160 in the gate, 

In a preferred embodiment, all messages flow toough a gate. A gate may be configured to provide a flow 
20 control mechanism. For example, a service may need to handle a large amount of incoming and outgoing messages. 
How control may allow a service to keep up with high traffic volume. Gates may be. configured to monitor 
messages for flow control tags. When a gate receives amessage^ it may examine diat message for a flow control tag. 
The flow control tags may be XML tags. A message may include either an OFF tag or an ON tag, for example. If a 
received message includes an OFF tag. the receiving gate will stop sradmg messages to its paired 
25 ifthe gate receives a message including an ON tag, it may resume sending messages. 

Thus, a service-side gate may monitor flie use of its resources and trigger flow control if use of its resour^ 
exceeds a threshold. For example, a service may reduce its load by sendmg messages including OFF tags to one or 
more cUent gates. The client gates receiving Ihe messages wifli OFF tags will stop sending messages to the savice. 
Pending messages in the chents may be buffered or may be handled by intenial flow control me^ 
30 service is able to handle more requests, it may send messages to one or more cUents with ON tags so that the cUents 
. may resmne sending messages. In other embodnnents, other, flow control tags may be supported m addition to or 
instead of ON and OFF. Other flow control tags may indicate to reduce message flow or tlwt message flow m^ be 
increased. 

. Message gates may be configured to perform resource monitoring. For example, since all messages may 
35 flow through a gate, the gate may be configured to manage and/or track a client's use of a service (and possibly its 
associated resources such as memory or threads). A gate may be configured to track the activity of a software 
program, such as a cUent, by monitoring how much a resource, such as a service, is used .or whidi and how many 
: service resomces are used. In one embodiment, a gate may generate or may fecilitate generation of a cUent activxty 
log. Each message and its destination or sendw may be logged. 
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A gate may also be configured to perfonn resoiffce monitoring for flow control from the local (sending) 
side of a gate pair. If the client exceeds an allocated bandwidth of service (or respinrce) usage, the gate may. 
automatically throttle back the flow of messages, for example. Thus, a client-side message gate may automatically 
trigger different flow control modes by monitoring the flow of outgoing messages. If the outgoing message flow 
5 exceeds a threshold, the gate may reduce or shut off its flow of outgoing messages. The threshold may be specified 
in a service's XML schema or advertisement In some embodiments, the tiireshold may be specified, only for 
messages using certain service resources or for all messages. 

The gate may also be configured to determine when message flow may be increased or resumed. In one 
embodiment, the gate may maintain a count of outgoing messages that have been sent without the matching reply 
10 (response) received. When matching responses are received by the cUent-side gate, the count of outstanding request 
messages may be dekremented. When the counts decrements below a specified outstanding request message 
threshold, the gate may increase or resume sending new request messages. . 

A gate may be configured to support naessage-based accounting and/or billing. A billing system may be 
ir^lemented based upon the number and/or land of messages sent and/or received by a message gate. Since all 
15 messages to and from a client may pass through a gate, the gate may be configured to facilitate charging a client for 
service usage, for example on a per message basis or "pay as you go". Thus, a billing system may be implemented 
within the distributed computing environment in which a user could be charged, for example, each time a message is 
sent and/or received by software running on behalf of the user. 

In one embodiment, a message gate may receive billing information from an XML schema, e.g. for a 
20 service. The billing infonnation may denote a billing policy and a charge-back URI. The charge-back URI may be 
used by the message gate to charge time or usage on behalf of a user. A message gate may make a charge-back by 
sending a charge message to the charge-back XJKI specified m the XML schema. Gates so configured m^ be 
refeired to as bill gates. The billing policy may mdicate charge amounts per message or per cumulative message 
totals, etc. The billing policy may indicate how much and/or how often (e.g. after every x number of messages sent 
25 and/or received) to charge the user. The policy may indicate that only certain types of messages trigger diarges, 
such a messages requesting a specified service resource. The biHing policy may also indicate different billing 
models for different clients or classes of clients. For example, a billing policy may be configured (e.g. in a service's 
XML schema) so that some clients may pay a one-time charge vfhea ttiey create a gate to access the service. The 
policy may mdicate clients that are to pay as they go (e.g. per message), or mzy indicate clients that are not to be 
30 charged at all. 

In some embodiments, ia client may be too thin to support a frill gate, or a client may not include software to 
directly participate in the distributed computing environment In such embodinients, a server (such as the space 
server in which the service is advertised or another server) may be a fiill or partial proxy gate for the client The 
server may instantiate a service agent (which may includQ a gate) for each service to be used by the client The 

35 service agent may verify permission to send messages; send messages to the provider, possibly queuing them until 
the provider can accept the next one; send messages to the client, possibly queuing them until the client can accept 
the next one; and manage the storing of results in a result or activation space. See also the Bridging section herein. 

For example, as illustrated in Figure 13, a client may be a conventional browser 400 that does not support 
gates to participate directly in the messaging scheme described above. The browser 400 may be aided by a proxy 

40 seivlet (agent) 402. The browser user may use a search engine to find a Web page that fronts (displays the conteiits 
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of) a space advertising services within the distributed computing environment The user is able to pomt andxlick on 
the space Web page and, with the help of the servlet, to access services. The Web pages may include scripts, for 
example, Java or WML scripts, which may be used in connecting the browser to the proxy servlet Scripts may also 
be used to send messages to the proxy servlet The servlet agent may translate Web page actions into messages on 
behalf of the browser client These actions may include navigating a space, starting services, and retummg results. 
Result page UKls (referencing pages containing XML) may be returned dkectly (or translated into HTML or WAP 
if needed) to the browser, for display to the user. Thus, the browser-based client does not need to know how to start 
services, nor which messages to send during the service usage session. For example, a user of a WAP browser (e.g. 
on a ceU phone) may connect to a space page, browse its contents (services), and then start a service, all by pomting 
and clicking. The agent 402 provides Ae client mterfece between the conventional cUent and the distributed 
computing environment 

The distributed computing environment may include several different types of message gates for 
communicating between cUents and services that support different features. For exan^Ie, as discussed above, some 
gates may support flow control or billing. Another type of message gate may support a form of remote method 
invocation. Thistypeof gate may be referred to as a method gate. 

A gate is a secure message endpoint that sends and receives type-safe messages, e.g. XML messages. The 
remote method invocation (RMI) style gate may be referred to as a method gate. The direct data-centric gate may be 
referred to as a message gate. A method gate may be implemented as a "layer^' on top of a message gate. The exact 
implementation may be defined in the platform binding. 

Figure 14 illustrates the use of a method gate to provide a remote method invocation interfece to a service. 
Method gates provide a method interface between clients and services. A metiiod gate may be bi-directional, 
allowing remote method invocations from client to service and from service to client A method gate 172 may be 
generated from XML schema information 170 (e.g. from a service advertisement in a space). The XML schema 
mfonnation 170 includes XML deiSning a method interfece(s). From this information, code may be generated as 
part of the gate for interfecing to one or more methods. Each method mvocation (e.g. fit>m a client application 176) 
m the generated code may cause a message to be sent to the service containing the marshaled metiiod parameters. 
The message syntax and parameters to be included may be specified in the XML schema. Thus, the method gate 
172 provides an XML message interfece to remotely mvoke a service method: The method gate may be generated 
on the client or proxied on a server, such as the space server \^^e^e the service method was advertised or a special 
gateway server. 

A service may have a corresponding metiiod gate tiiat implements or is linked to a set of object methods 
that correspond to the set of metiiod messages defined in tiie service's XML schema. There may be a one to one 
correspondence between tiie object metiiods implemented by or linked to tiie service's method gate and tiie metiiod 
messages defined by tiie service's XML schema. Once a service's corresponding metiiod receives a message from a 
client to mvoke one of tiie service's metiiods, the service's metiiod gate may unmarshal or unpack tiie parameters of 
tiie message invocation and tiien invoke tiie metiiod indicated by tiie received message and pass tiie unmarshaUed 



Hie metiiod gate may provide a synchronous request-response message mterface in which clients remotely 
caU metiiods causing services to return results. The underlying message passing mechanics may be completely 
hidden fixim tiie cHent This form of remote method invocation may deal witii metiiod results as foUows, Instead of 
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downloading result objects (an<3 associated classes) into the client, only a result reference or references are returned 
in XML messages, in one embodiment An object reference 178 may be a generated code proxy (e.g. results gate) 
representing the real object result 180 (stiU stored out on the net, for example). Li o&er embodiments, the client 
may choose to receive the actual result object In addition, once a client has received a result object reference, the 
client may use this reference to receive or manipulate the actual result object In one embodiment, the result 
reference inchides one or more URIs to the real result 

The real result object(s) may be stored in a service results space (which may be created dynamically by a 
servht, for example). This temporary results space may act as a query results cache. The results cache (space) may ; 
be patrolled by server software (garbage collector) that cleans up old result areas. Results returned from each 
method invocation may be advertised in the results space. A result itself may be or may include a method that could 
then be remotely instantiated by a client, thus generating its own method gate. Therefore, the distributed computmg 
environment may support recursive remote method invocation. 

As mentioned above, when a client uses a method gate to remotely invoke a service method, a reference to 
the method resufts may be returned from the service metiiod gate instead of the actual results. From this reference, a 
results gate may be generated to access the actual result Thus, the client or cHent method gate may receive a result 
URl and perhaps a result XML schema and/or authentication credential for constructing a gate to access the remote 
method results. 

In one embodiment, a service gate may create a "child gate" for the results. This child results gate may 
share the same authentication credential as its parent gate. In some embodiments, results may have a different set of 
access rights and thus may not share the same authentication credential as its parent For example, a payroll service 
may allow a different set of users to initiate than to read the payroll service's results (paychecks). 

A service method gate may return a child results gate to the client gate as the result of the method. The 
client may tiien use the results gate to access the actual results. In one embodiment, tiie software program (client) 
receiving the results gate cannot distinguish between die results gate and the result itself in which case . the results 
gate may be an object proxy for the actual result object The results gate may also be a method gate that supports 
remote method invocation to result objects, hi this manner, a cham of parent and child mediod/results gates may be 
created- 

In one embodiment, the method gates and remote methods may be in Java. In this embodiment, method 
results are correctly typed according to the Java typing system. When a Java method is remotely invoked as 
described above, the results gate may be cast mto the Java type that matches tiie result type. In this embodiment, 
method gates may be used in &e distributed computing environment to allow remote Java objects to behave as local 
Java objects. The method invocation and results may appear the same to the client Java software program whether 
the real object is local or remote. 

See the Spaces section below for a forther discussion on the use of spaces for results. 

Message gates may also support publish and subscribe message passing for events. Message gates with 
event support may be referred to as event gates. A service's XML schema may mdicate a set of one or more events 
that may be published by the service. An event gate may be constructed from the XML schema. The event gate 
may be configured to recognize some or all of the set of events published by a service, subscribe to those events, and 
distribute each event as the event is produced by the service. 
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The set of events for a service may be described in the service's XML message schema. For each event 
message in the XML schema, the event gate may subscribe itself as a consumer of that event In one embodiment, 
an event gate subscribes to all events indicated by the XML schema. Each event message m^ be named usmg an 
XML tag. The event gate may subscribe by sending a subscription message including the XML tag for the event to 
be subscribed to. 

When a correspondmg event occurs with the service, tiie service may send an event message to subscribers 
indicating the occurrence of the event Hie event message may contdn an XML event document and may be sent to 
each subscribed gate. When a subscribed gate receives the event message, the XML event document is removed 
from the message and the process of distribution begins. Event distribution is the process of handing out the event 

) document within the client platform. Each event consumer within the cUent platform may subscribe with the event 
gate for each type of event On Java platfonns, the typing system is Java (converted from^A^ 

The event consumer may supply an event handler callback method to tiie event gate. The event gate may 
store a list of these subscriptions. As each event message arrives at the gate (from the service producing the event), 
the gate traverses the list of client consumers and calls each handler method, passing the XML event document as a 

5 parameter. In one embodiment, the XML event document is the only parameter passed to the handler callback 
method. 

In one embodiment the event gate automatically subscribes itself for events on behalf of the local consumer 
clients. As clients register interest with the gate, the gate registers mterest with the event producer service. A client 
may also un-subscribe interest, which causes the gate to un-register itself with the service producing the event 
20 An event gate may type check the event document using the XML schema just like a regular message gate 

does in the standard request-response message passing style described above. An event gate m^ also mclude an 
authentication credential m messages it sends arid verify the authentication credentials of received event messages. 

Note that any combination of the gate fimctionality described above may be supported in a smgle gate. 
Each type has been described separately only for clarity. For exan^le. a gate may be a message gate, a method gate 
25 and an event gate, and may support flow control and resource monitoring 

Service Discovery Mechanisms 

In one embodhnent, the distributed computmg environment may include a service discovery mechanism 
that provides methods for clients to find services and to negotiate the rights to use some or aU of a service's 
30 capabilities. Note that a space is an example of a service. The service discovery mechanism m^ be secure, and 
tnay track and match outgomg cHent requests with incoming service response 

A service discovery mechanism may provide various capabilities including, but not Innited to: 
• Finding a service using flexible search criteria 

o Requesting an authorization mechanism, for example, an autiientication credential, that may convey to the 
35 client the right to use tiie entire set or a subset of tiie entire set of a service's capabilities. 

o Requesting a credential, document, or o&er object that may convey to the client the service's mterfece. In 
one embodiment, the service's mterface may include interfeces to a requested set of the service's 
* capabilities. 



29 



wo 01/86394 



PCTAJSOl/15134 



The tracking of discovery responses to the original requests. In one embodiment, each client request may 
include a collection of data that may also be returned in matchuig responses, thus allowing the requests and 
responses to be correlated. 

In one embodiment of the distributed computing environment, a service discovery mechanism may provide 
a flexible search criteria based upon an extensible grainmar. In one embodiment, a service name, service type, and 
other elements, if any, being searched for may be matched with elements in an XML document In one embodiment, 
tiie XML document is the service advertisement for the service. XML may provide a flexible, extensible grammar 
for searching. XML also may provide type safety for matching elements* In one embodiment, the service names 
and service types may be type checked widi the element types m the XML service advertisement 

In one embodiment, a distributed computmg environment may include a mechanism for clients to negotiate 
service access rights. In one embodiment, the mechanism may be used to negotiate for a subset of a service's fiall 
c^abiMes. The result of the negotiation may be an auftorization such as an authentication credential that conveys 
to die client the right to use tiiis requested subset of the service's capabilities. 

In one embodiment, the service discovery mechanism may allow a client to request a security capability 
credential from a service. In one embodiment, the client may present to the service a set of desired capabilities in 
the form of a protected (secure) advertisement The service may then respond with a c^ability credential that may 
convey to the client the rights to use the requested capabilities described in the protected advertisement 

hi one embodiment, the distributed coinputing environment may include a mechanism for a client to 
negotiate service access rights and to then obtain a security credential or document that may be used to present the 
service's access interface to the set or subset of the service's capabilities that were requested by the client 

In one embodiment, a client that receives a capability credential from a service may generate a custom 
service access interfece document that may be referred to as a "complete advertisement" In one embodiment, the 
complete advertisement may be an XML document The generated advertisement may provide access to the service 
capabilities as granted to the client by the received capability credential. In one embodiment, an interface may be 
provided by . the advertisement only to the service capabilities to which the client has beeni granted access by the 
capability credential. In one embodiment, the client may be granted access to only required capabilities and to 
which the client has access privileges. 

In one embodiment, the distributed computing environment may provide a mechanism by which a client 
may negotiate capabilities with services. In one embodiment, the client may negotiate its capabilities to the service. 
The service may then customize results based on the parameters negotiated with the client For exainple, a client 
that is capable of one bit display at a resolution of 160x200 may negotiate these parameters to the. service, thus 
allowing the service to customize results for the client 

The following is included as an example of an XML cq>abilities message and is not intended to be limiting 
in any way: 

<type name="Capabilities"> 

<element name^^display" type="strmg"y> 
<clement nanie="memory" type="string"/> 
<elementname=''mm:ie" t>Tpe="string*'> 
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</type> 

The distributed computing environment may inchide a mechanism that may allow clients to negotiate how a 
service is to return results of a service invocation. In one embodiment, during a capability credential request, a 
means by which to choose one of the results return methods may be conveyed to the seryice. The service may then 
generate a custom service advertisement that may convey to the client the results inechanism to be used, as well as 
the service interfiace. 

Thus, the service discovery protocol may allow clients to search for services (both space services and 
specific services or types of services). Service providers (or a listener agent) may respond to search requests by 
publishing or providing corresponding advertisements or URIs to conresponding advertisements. When a service 
provider responds to a discovesry search request (either directly or through a listener agent), the provider may choose 
to publish a protected or an un-protected (complete) advertisement A protected advertisanent may mclude the set 
of information necessary to obtain a complete advertisement Publishing a protected advartisanent forces the client 
to obtain a valid credential from an authentication service before receiving the complete un-protected advertisement 
from the service provider. A complete un-protected advertisement is needed to create a g&te, and dierefore to use 
the seryice. Forcing clients to obtain a valid credential before receiving an advertisement may provide an additional 
level of security for the service provider. The security credential that must be obtained to receive the complete 
advertisement may be the same security credential that is used to construct a gate to communicate with the service 
where the gate embeds the security credential in each message to the service. 

Whether or not a service provider publishes a protected or con^lete advertisement may be based upon the 
service provider's desired level of security. Complete advertisements contain the service's message endpoint URL 
Concealing this address inay be a desirable security feature m many kinds of networks and deployment 
environments. However, simple proxunity networics like IRDA, validate clients by requiring the cUenl be m close 
proximity to the service provider. Concealing the IRDA message address from a close proximity client may just be 
redundant or too burdensome. In either case, the discovery search response choice may be left to the service 
provider. In a preferred embodiment, clients (or client gate factories) are configured to process either search 
response. 

Tuinmg now to Fig. 41, a flow chart illustrating service discovery is illustrated according to one 
embodunent A client locates one or more advertisements for service(s) the client may desire to use, as indicated at 
2072. In one embodiment, the client may locate services by sending a search message. Turning now to Fig: 42, a 
flow chart ilhjstratmg a more detailed exanqple of locatmg service advertisements is illustrated for one embodiment 
The client may send (e.g. broadcast; multicast, etc) a search message nidicating service name and/or ser^dce type 
search criteria, as indicated at 2071. 

The following is an example for one embodiment of a search message that may be sent on one or more 
available message traiisports when a client wishes to search for services; 

<Discover> 

<Search> • 
<SearchType> Type<SearchType> 
<SearchName> Name</SearchName> 
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<SearchConiment>Coinment</SeardiConiment> 

</Search> 
<yDiscovei> 

5 TUe seaich message is formatted according to a data representational language. Tbc search and discovery 

tags may be required. TT,e search tags may contain an optional set of search criteria, useM for narrowing the 
possible results returned from service provider. The optional search criteria components may inchide a name (e.g. 
String). The name is compared with a service's name. If the search name matches the bcgimjing or all of the 
service'snaine,ainatchmaybedeclaredfortbatservice. In one embodiment, iftbe name isn't provided, all service 

10 names are considered a match. 

Tte optional search criteria components may also inckute a type (e.g. string), m 

the service type. e.g. m fte service description's "Tifle?' field. If tbe seaich type matd.es the beginning or all of the 
service's m a match may be declared. In one embodiment, if the type isn't provided, all service types are 
considered a match. For example, the type string may be "space" when operating on a large network or "service" 
15 when operating in a proximity network. Additional levels of type may be employed. 

nius, as indicated at 2072 in Fig. 42. flie service name and/or service type seaich «iteria may be con5»ared 
tonameandtypeinfonnationforseiviceswitbinftedislnTnitBdcomp^ Each service provider that 

receives the search message may perform thfa comparison. Or a Ustener agent may perform the comparison for 
services registered with the listener agent 
20 Tlie optional search criteria components may also include a comment (e.g. String). TTie comment string 

may be returned in the body of the response message, and may be a useful discovery message tracking tooL For 
example, a tnnestamp might be a useful comment string. 

A search response may then be returned to tiie client indicating advertisements for services that match the 
search criteria. Die foUowing is an example for one embodiment of a service provider response message that may 
25 be sent (e.g. umcast) by a service provider in response to the search message: 

<Discover> 
<SearchResponse> 

<SearchComment;^ Comment String</SearchComment> 
30 <;Advertisement> Advertisementl </Advertisemcnt> 

<Advertisement> Advertisement! </Advertisemenj?^ 
<Advertisement> AdvertisementN <Advcrtisemeiil> 

<SeaichResponse> 
</Disco\ei> 



35 



Hie response message may include the set of advertisements that match the seardi criteria. In one 
embodiment, if the search criteria weren't suppUed, all available advertisements are defined as a match. In one 
embodhnent, if a comment string was supplied, the response also contains tiiat same comment, possibly with an 
additional comment appended to the end of the ori^aial string. 



32 



wo 01/86394 



PCr/USOl/15134 



As mentioned above, a service may publish either a protected advertisement or a complete advertisement 
Thus the advertisements indicated in a response to a search m^ be protected or complete advertisements. A 
protected advertisement may not indicate the actual mi or schema that may be used to access the service. Instead, 
a protected advertisement may contain information on how to obtmn a complete advertisement that includes the URI 
5 and schema to access some or all of a. service's capabilities. In one embodiment, a protected advertisement may 
include the following information: 
° Name and type of the service. 
« Capability descriptions of the service, 
o UUIP of the service. 
10 *» URI ofauthentication service, v\4uchwiD return a suitable cUent access (capab^^ 

* XJM\siere the credential and UUID may be soat to g©aer^ 

A protected advertisement may be a smaller, surrogate XML document fragment (a meta-advertisement). 
A protected advertisement may provide a level of indirection between the client and the real advertisement, 
reqnning the client to negotiate for access to the real advertisement Publishing a protected advertisement instead of 
15 a complete advertisement forces the client to obtain a valid credential from an authentication service before 
receiving the complete un-protected advertisement from flie service provider. 

Returning to Fig. 41, after the client receives a response to it s seardi, it may select one of the 
advertisements for one of the services for which it wishes to negotiate access by requesting a capability credential, 
as indicated at 2074. This advertisement negotiation process may provide additional security in the distributed 
20 computing environment (e.g. by hiding real advertisements), while at the same time adding some flexibility. For 
example, during the advertisement negotiation process, a client may request a custom set of messages for accessing 
the service. The client may provide die desired name and type of mterface. One example of requesting a custom set 
of messages may be requesting only ''read" acceiss as opposed to "read" and •*write" access to a service. When 
requesting a custom message set, the client may wish to only use a subset of the service's fiill capabilities 
25 (messages). The right to use the requested set of messages may be verified durmg the negotiation. If the client 
doesn't have the proper access rights to the requested capabilities, the negotiation fails, otherwise a valid credential 
. is retumed to the client 

A client may also request additional access message sets. Client may provide the desired name and type of 
mterfece. Some clients may require the use of more than just the base access messages. A client m^ request a set 
30 of additional access messages. Some of these access messages may even address platfomi specific issues such as 
performance and memory footprint size. 

A client may also request that a non-XML content type be used to represent data passed m the messages 
between client and service. Some clients may not support XML, but still wish to access services withm the 
distributed computing environment To allow non-XML clients access to services, nonrXML content m^ be 
35 tunneled within an XML message. The non-XML content may be wrapped by an XML tag on tibie sendmg side, and 
then extracted on the receiving side. 

Service providers may benefit from the use of protected advertisements in several ways. As ahready 
mentioned, protected advertisements prevent unauthorized clients from receiving complete advertisements, and 
allow capability negotiation. Protected advertisements may also allow for dynamic advertisement generation. When 
40 a client negotiates for a complete advertisement, an opportunity to generate a custom one "on the fly" exists, Hiis 
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feature aUows smaller XML document fragments to be downloaded to cUents since the complete advertisement need 
be only as big as requested. This feature also allows a service to effectively publish advertisements specific to client 
requirements. 

Protected advertisements may also fecilitate service queries. Protected advertisements may be published 
5 mstead of complete advertisements to facilitate dynamic searches for services that match the client requested set of 
capabilities. Protected advertisements may indicate a service's capabUities in a searchable format without including 
a complete message schema for those fecilities. 

In one embodiment, a protected advertisement may include the foUowing X^4L document eleme 

o Name (Hmnan readable, non-canonical string) 
lb *» Canonical name of service (e.g. UUID) 

• Base Method Into^ce Description (Message InterfeceDescripti 

- Title (Message interfrice standard name that conveys a type) 
Provider Name (Standards Body Name) 

-Version (Version of standard (type) implemented) 
15 - Info URI (Standard body's web page) 

<» Additional Access Method Interfece Descriptions 

- List of descriptions containing: raie. Provider, Version, Mo URL 

• Content Type I^cscriptions 

-List of descriptions containing: Title, Provider, Version, Info URI. 

20 * Credential 

- Service's credential to enable.client to authenticate service 

• Authentication URI 

- A message may be sent here to obtain a suitable credential that grants access to this service. 
« Generate Real Advertisement URI 
25 - A message may be sent here to generate a complete advertisement, given a protected advertisement 

that contains the client's requested capabilities. 
To obtain a complete advertisement, given a protected advertisement, a client (e.g. client's gate fectory) 
obtains a capability credential from the specified authentication service by sending a credential request message, as 
indicated at 2074 m Fig. 41. The credential request message niay be se;nt to an authenticated service tIRI specffi 
3d m Ae advertisement for the service the client desires to access. When the client's requt?st is received, a capability 
credential is generated, as indicated at 2075, The capability credential may be generated according to capabilities 
requested by the client and/or the client's level of authorization. The client then receives the capability credential in 
response to its request, as mdicated at 2076. . The response may contain tiie credential needed to generate the 
complete advertisement This credential may be the same credential that the cUent's gate mcludes in each message 
35 sent to the service. 

If &e advertisement was a protected advertisement, the client then may send an advertisdment request 
message containing tiie capability credential and an identification (e.g. UUID) of the service to tiie second URI 
. specified in the protected advertisement, as Micated at 2078. The cUent tiien receives a complete advertisement, as 
indicated at 2080. The response to this second message is the complete advertisement of the specified scivice. If 
40 the advertisement indicated in the credential request was akeady a complete advertisement, 2078 and 2080 may be 
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skqjped. Figure 43 compares the difference in liie discover process when tiie published adv^tisement is a complete 
advertisement versus a protected advertisement Returning to Fig. 42, a complete advertisemait and the capabUity 
credential may then be used to create a gate, as indicated at 2082. 

An example of a credential request message according to one embodiment is as follows: 

5 ' • • ■ ' . 

<Discpver> 
<CredentialRequest> 

<UUID> uuid<AJUID> 

<AdvertisementXJRI>adv urWAdvertisementURJ> 
10 <protectedAdvertisement>adv</ProtectedAdvertisement> 
</OedentialRBquest?> 
</Discover> 

The credential request message may include an identification (e.g. UUIT)) of service to which access is 
15 desired. The credential request message may also include an advertisement URI referencing the advertisement or 
tiie advertisement (by value). The Advertisem^ may be passed by vahie or by refereaice during tiiis 
process. Advertisements inay be complete or protected. If the advertiseatnent pa^ in the credential request 
message is already a complete advertisement (e.g. service returned it in the se^ response), then the credential 
returned from tiie service will allow access to all of the service's capabilities (all access methods + all messages). 
20 A protected advertisement may be edited to contam just the desired set of access method and content 

descriptions: The edited protected advertisement may be passed m tiie credential request message. Thus, a client 
may build and expresses its set of requested capabilities by editing the advertisement, or copying tiie relevant 
information from the original to a new instance. 

An example of a credential request response message according to one embodimait is as follows: 

25 . 

<I>iscovei:> 

<CredentialRequestRespoiise> 

<Oredential>capability credential<;^Credential> 
</CredentialRequestResponse> 
30 </Discover> 

If the client has proper autiiorization, the credential request response message includes a capability 
credential giving the client requested access to the specified service (e.g. identified by UUID), including the set of 
capabilities defined m tiie protected advertisement Hiis credential may tiien be stored m tiie cKenfs gate and tiien 
35 added to each message sent to tiie service. The service tiien uses tiiis credential to vaify tiie client's right to use a 
service's capabilities. 

The capability credential structure and contents may be defined by tiie service. In one embodiment, tiie 
credential at least inchides a reference to tiie protected advertisement used during tiie negotiation, and a security key 
to validate the cHent's identity. If tiie advertisement passed m tiie credential request message is aheady a conq)lete 
40 adveitisemait (e.g. service returned it m tiie search response), tinien tiie credential returned from tiie service will 
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allow access to all of the service's capabilities. If the service provider doesn't s\q)port or require credentials at all, 
the response message may contain an einpty credential (null). 

In some embodiments, a capability credential may be used to support the notion of sessions, A service 
provider may embed a session ID within the credential, and be sure that tiie client gate will pass it (credential 
5 contaming ID) to the service provider in each message. The entire d^ntial may be defined by the service provider 
and hence may contain any number of fields^ includmg a sessionID, or other demuxmg IDs, etc: 

An example of an advertisement request message according to one embodiment is as Mows: 

<Discover> 
10 <Adv«tisementRequest> 

<Credentia> capability credential<^Ciedentia> 
</AdvertisementRequest> 
</Disc6ver> 

15 The advertisement request message includes the credential from the credential request response message. 

In one embodiment, this credential includes enougjb information to identify the origmal protected advertisemeuL 

An example of an advertisement request response message according to one embodnnent is as follov^: 

20 . <Discover> 

<AdvertisementRequestResponse> 

<Advertisement> ConapleteAdvertisementl </Advertisem«it> 
</AdvertisementRequestResponse> 
</Discover> 

25" 

The advertisement request response message mcludes the complete advertisement ref^enced by the 
(edited) protected advertisement Note tiiat the credential found in tiie complete advertisement m^ be the gate 
credential to be passed in every message. 

Spaces are implemented by services of type space. Discovering a space may be accomplished either by 
30 specifying the "space" type in tiie search criteria, or by parsing the set of search results, and tiien exlractmg aU 
"space" advertisements. Spaces may be populated with advertisements (protected or unprotected) using the above 
described discovery protocol The population may be initiated by the space service itselt or by another network 
service agent 

Once a space is discovered, its contents may be examined usmg standard space service navigation 
35 messages or as defined iii the space service advertisement For each advertisement wthin the space, a client gate 
factoiy may build a gate (using the credential and advertisement request messages) to access the named service. 

In one embodiment aU advertisements (protected and complete) contain a service credential CUents may. 
vahdate tiiis credential before requesting a client capability credential This procedure m^ prevent un-authorized 
semces fix)m publishmg advertisements using die discovery protocol 
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For one discovoy protocol implementation example, the protocol may be 'on tfie wire data format, \Aich 
may be implemented in many different ways depending on the transport bene^ it Hie discovery protocol 
implementation may be defined in a platfom. binding. For example, a possible IP implementation may be one in 
which space services listen for UDP multicasts of space search messages. A client/service may multicast a space 
5 search message and waits for a response. Space services may anicast a space search response message containing an 
advertisement 

In one embodiment, the dism^uted computing enviromnent may inc^^ 
discovery search requests and responses to the requests. In one embodhnent, search request and response messages 
may include a field that may be used to include a string or an XML document In one embodiment, the string or 
LO XML document included m tiie field of a request message is also returned in the response message.. In one 
embodiment, Ae string or XML document is required to be reta^ 
the string or XML document may inchide additional information inse^ 

when returned in the response message, hi one embodhnent, this mechanism may be used in debu^ complex 
systems. In one embodiment, this mechanism may also provide to clients a method for choosmg services to access 
15 by using the string or XML document to pass custom search information between a cHent and service diat may only 
be understood by the client and service. 

For an example of fields m request and response mess^es, refer to the SearchComment field in the search 
and search response messages described above. 

For some devices that provide a service, the overhead of finding a space to advertise its service and 
20 maintain that advertisement is undesirable. . In one embodhnent, rather than 

spaces to pubHsh service advertisements, services on some devices may transmit their advertisements in response to 
connection requests. For example, a printer device with a printer service that is available on a proximity basis may 
not mamtain an advertisement in a space (on the device or external to the device). Instead, when another device 
establishes a connection with the printer device (for example, a user with a l^top running a cUent deshes to print a 
25 document), the printer service may transmit the service advertisement to provide the XML service schema for 
comiectbg to and running the service that provides printing fimctionality o 

may only maintain advertisements for tiieir services in a certain vicmity or local network. Such a device may not 
deshe to support or may not have access to transports for broader accessibility. 

One example of a service device in whidi it may be desirable for the device to avoid or limit maintainmg 
30 service advertisements m a space is a device whose fimctionality is available on a proxhnity basis. Proximity-based 
services may provide advertisements of their fimctionality upon request These advertisements may not be broadly 
accessible. For example, proximity-based services may be provided in a wireless communications system. Tbe term 
"wireless" may refer to a communications, monitoring, or control system in vMch electromagnetic or acoustic 
waves cany a signal through atmospheric space rather than along a wke. In most wkeless systems, radio firequency 
35 (RF) or infrared (JR) waves are used. Typically, in proximity-based wireless systems, a device comprising a 
transceiver must be within range (proxhnity) of anoth^er de>dce to establish and mamtdn a Communications channel 
A device may be a hub to connect other devices to a wkeless Local Area Networic (LAN). 

As mentioned, embodhnents of the distributed computing environment may provide a mechanism usmg one 
or more spaces that aUow clients to rendezvous with services. In a proxhnity computing envhonment, one 
40 embodhnent of the distributed computing environment may provide a service discovery mechanism tiiat cUents may 
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use to discover services without using spaces as rendezvous points. An example of a proximity computing 
environment is an IrD A point-to-point communications environment In a proximity computinjg environment, , tbo 
proximity mechanism may find the "physical" location of the service for &e client For example, in an IrDA 
environment, the client device may be physically pointed at the device including the service(s) that the cHent desires 
5 to use. 

In some situations a cUent may have physically discovered the device that contains services the cUent 
desffes to nm. For example, a percon with a PDA client may be in close proximity to a printer participatmg within 
tiie distributed computing environment Various scenarios may emerge with close proxhnity devices. When cUents 
are in close proximity to devices (e.g, pubUshing services), much of the discovery process may be simplified. In 
10 these cases, the user may select the device. For example, IRDA devices are pointed at each other to establish a 
disco ver connectioiL 

Close proxhnity devices for vMdti security isn't an issue (like an IRDA printer) may publish complete 
advertisements. Instead of encq)sulatmg services m spaces, close proximity devices may directly respond to the 
discovery protocol. 

15 Close proximity devices for whidi security is an issue (e.g. an A™0 ^ respond to discover requests 

wi^ protected space advertisements. The space may contan aU the services supported by the device. Once access 
to the space has been granted, cUents m^ browse complete advertisements stored in the space, TOs model 
presumes that all services stored in the space can leverage the space security model, and not provide a separate 
model. Alternatively, close prowmity devices for which security is an issue may respond to discover requests with 
20 protected advertisements for each service. Each service may provide its own authentication service. Combmations 
of.each proximity device scenario are also contemplated. 

The proximity service discovery mechanism may enable the cUent to directiy look for service 
advertisements ratiier tiian sending a search request to a space to look for sendee advertisements. Suxce tiie cUent 
device may have established a proximity connection to the service device, the client may directiy request tiie desired 
25 service. For example, a PDA client device may establish a proxhnity connection to a printer device; the client may 
"know" to request a printer service connection on the printer device. 

In one embodiment, the client may send a proximity service discovery message to the service device. The 
message may include mformation tiiat may specify a desired service on tiie service device to wluch tiie client device 
has a proxunity connection. In one embodhnent, a service on tiie service device m^ respond to tiie proxhnity 
30 service discovery message, and may send to tiie cUent tiie service advertisement tiiat tiie cUent may use to connect to 
tiie desired service. The proximity service discovery message may also include information tiiat may be used to 
autiienticate tiie client and to establish tiie cUent's capabilities on tiie service. Usmg tiie received service 
advertisement, tiie client may establish a gate to establish communication with tiie desued service. 

An example of a system m v^Wch a client device directiy discovOT a service m a service device ovct a 
35 proximity Imk is fllustrated in Fig. 44; A cUent device 2150 mcludes a proximity port (e.g. an IrDA port) 2156 
configured to form a direct pomt-to-point communication link, or proxnnity Imk. CUent device 2150 m^ include a 
client 2152 tiiat may desire to use a service over tfie proxunity link. Hie client 2150 may be an qjplication or a 
/ . combination of circuitry and software. A cUent interface 2154 may be configured to. directiy request over tiie 
proximity link a document tiiat describes an mterfepe to access a desired service. The interfece 2154 may also be 
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configured to receive such a document directly over the pomt-to-point communication link and use the infonnatici>n 
from the document to access the service, such as by constructing a gate. 

A service device 2170 may include a proximity port 2172 and may form a proximity link with client device 
2150. The service device 2170 may include code and/or hardware to implement one or more services 2176. 
Service device 2178 may also be configured to provide one or more documents 2178, or advertisements, over the 
proximity linL An advertisement 2178 may describe a message schema for accessing a service 2176 provided by 
service device 2170. A service interface 2174 may be configured to receive over the proximity link a request from a 
client for a document 2178 that describes an interfece to access a service 2176. The mterfece 2174 miay also be 
configured to provide document directly to a client over the proximity link and provide a message endppint (e.g. 
gate) for communicating with a client The service interfece may also provide a mechanism to authenticate clients' 
requests to access the service. 

Figure 45 illustrates a basic flow diagram iUustradng client discovery of a proximity service, A client may 
form a proxnnity connection to a service device, as indicated at 2190. For example, a client device may be a 
personal digital assistant (PDA) with an address book client The client my need to print a portion of the address 
book. The PDA may include an IrDA port and may be in proximity of a printer with an IrDA port The client may 
establish a proxunity connection to the printer. The client miay then, as indicated at 2192, request a service 
advertisement over the proximity connection, such as a printer service advertisement Then client may then receive 
an advertisement matching its request, as indicated at 2194. The advertisement may be received dhectly from the 
service device over the proximity connection. The client may then construct a gate accordmg to the advertisement 
to access the service, as indicated at 2196. 

Thus, proximity devices may avoid the overhead of using spaces as a rendezvous point for clients 
discovering services. Nevertheless, it may still be desirable to publish advertisements for services (e.g. proximity- 
based services) that do not deshe to or cannot maintain theh advertisements in a space ttiat is broadly accessible. In 
one embodiment of a distributed computing environment, a device that establishes a connection with a device that 
does not publish its service advertisement(s), such as a proximity-based device, may publish service advertisements 
received from the non-publishing device. For example, a device that establishes a connection with a proximity- 
based device and that has an ahemate transport connection(s) may publish (or republish) service advertisements 
received from the proximity-based device in the alternate transport enviroEutnent, thus allowing die proximity-based 
device service(s) to be used by other devices (through the (re)published service advertisements) which are outside 
the normal proximity range of the device. 

The publishing device may locate a locally published service advertisement for the proxnnity-based device 
through a discovery and/or lookup service, or ahematively the service advertisement may not be published by the 
local service device, but mstead may be sent to the publishing device by Ac local device upon the establishment of a 
proxnnity connection, as described above. In one embodiment, the r^ublished service advertisement may be made 
available as long as the device maintaining tiie advertisement is connected to or able to connect to the local device. 
For example, if the publishing device is disconnected from the local device (for example, moves out of proximity 
range of die device), the service advertisement m^ be made stale or removed. A lease mechanism may be provided 
to allow the space contaming the advertisement to send lease renewal messages to the publishhig device. The 
' publishhig device may verify its connection to the local device, thus allowing the space to detect when tiie local 
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device is no longer available. Rules for how the service advertisements are republished may be provided by tiie 
local device or by an administrative policy for the local vicinity (e.g. proximity area) or local network. 

Figure 24 illustrates an example of a device bridging proximity-based devices onto another transport 
mechanism to allow the services provided by the proximity-based devices to be accessed by devices outside the 
5 proximity range of the devices, according to one embodhnent A publishing device 1404 may be connected to a 
network 1412, such as an Ethernet LAN or the hitemet, etc., and may establish and maintain proximity corinections 
1414 with proximity devices 1400 and 1404. Prowmity connections may be wheless connections or wired LAN 
connections, for example. Proximity devices 1400 and 1402 njay each send a service advertisement to the 
publishing device 1404 upon connection, or, alternatively, the publishing device may locate the service 
10 advertisements using a discovery and/or lookup service for die proximity connections. The publishing device 1404 
m^ tiien make the services provided by the proxinuty devices available to o&er devices 1408 and 1410 on the 
network 1412 by republishing the service advertisements 1416 and 1418 m space 1406. Space 1406 may be stored 
on the publisMng device or on other devices connected to the LAN (including devices 1408 and 1410). 

Other devices on the LAN including devices 1408 and 1410 may then discover space 1406 and look up the 
15 republished service advertisements 1416 and 1418 for the proximity-based devices, establish gates to communicate 
to those services (device 1404 may act as a proxy or bridge) on the proximity-based devices 1400 and 1402 using 
tiie XML message passing methods described previously, and send requests and receive results to the proximity 
devices. Publishmg device 1404 may act as a bridge between the network 1412 and the proximity connections 1414 
to the proximity-based devices. . 

20 

Matching Component f Service'^ Interfaces 

The distributed computing environment may provide a mechanism for matchmg a component (for example, 
a service) specification interface with a requested interface. For example, a client (which may be a service) may 
desire a service that meets a set of mterface r^uirements. Each component may have a description of the interface 

25 to which it conforms. The specification interface matchmg mechanism may allow a component that best matches a 
requestor's interface reqmrements to be located. The specification interface matching mechanism may also allow 
for "fuzzy" matching of interface requiremMits. In other words, the mechanism may allow matching without 
requiring the exact specification of all aspects of tiie interface, thus providing a nearest match (fiiaay) mechanism. 
In one embodhnent, the specification mterface matdimg mechanism may be implemented as a multi-level, sub- 

30 classing model rather than requhring specification at a single interface leveL 

In one embodiment, a component may use an XML Schema DelBnition Language (XSDL) to describe its 
interface. XSDL may provide a human-interpretable language for describing the mterface, sin^lifying activities 
requiring human mtervention such as debuggmg. In one embodhnent, the interface desaiption may be provided as 
part of an advertisement (for example, a service advertisement) as desaribed elsewhere in this document 

35 Usmg the specification interface matching mechanism, a basic desired interface may be compared to a set 

of component* mterface descriptions. One or more components matching the basic desired mterface may be 
identified. The mterface descriptions may include subclass descriptions describing more specifically the mterfeces 
provided by the components. In the search process, the class type hierarchy m^ be exammed to determine if a 
given class is a subclass of the search type. In one embodiment, subclasses may iriierit properties of the base class, 

40 and thus the subclass-specific mfonnation may not be exammed in this phase. Thus, the search may be performed 

40 



wo 01/86394 



PCTAJSOl/15134 



generically. The identified components may be searched at the next (subclass) level. The search may become 
specific to the subclass and may be perfonned by interpreting Ihe subclass information inchided m the interface 
description. The search may continue through one or more subclasses until one or more components is determined 
vidiich may provide the nearest match to the requestor's desired interface. 

In one embodiment, an interface matching medianism may provide the ability to distinguish among two or 
more components that implement similar interfeces. In one embodiment, the interface matching mechanism may 
provide the ability to distinguish among different revisions of the s 

In one embodiment, a con^onent description may be provided that includes a specification of the interfece 
to \^ch tiie component conforms. Tbe component descrqrtion may also include information about the component 
itself The iaterfece description and/or the component iiformation may be used to diflferentiate airiong diffaent 
implemaitations of a given interface. The conq)anent descnptions may include a canonical identifier and versioa 
infonnation. The version information m^ allow conqwnent revisions to be distinguished. In one ^nbodiment, the 
component description may be provided as part of an advertisement (for example, a service advertisement) as 
described elsewhere in this docunient 
15 In one embodunent, components niay be searched for a particular canonical identifier. Two or more 

con^nents may be identified with matching canonical identifiers. One or more components m^ be selected Ami 
among the components with matching canonical identifiers. The selection procedure may use an interfece 
specification yersion, a component implementation specification, a component implementation specification version, 
other mformation or a combination of information fi-om the component description to produce a set of one or more 
20 components that best match the requestor's requirements. 
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As mentioned above, the distributed computing environihent relies on spaces to provide a rendezvous 
mechanism that brokers services or content to clients. Figure 15 illustrates the basic use of a space 114, Service 

25 providers may advertise services m a space 114. Cfients 110 may find the advertisements m a space 114 and use the 
information from an advertisement to access a service using the XML messagmg mechanism of the distributed 
computing envu-onment Many spaces may exist, each containing XML advertisements that describe services or 
content Thus, a space may be a repository of XML advertisements of services and/or XML data, which may be raw 
data or advertisements for data, such as results. 

30 A space itself is a service. Like any service, aspace has an advertisement, wbkii a client of tiie space nnist 

first obtain in order to be able to run that space service. A space's own advertisement may include an XML schema, 
a credential or credentials, and a URI which indicate how to access Ihe space. A client may construct a gate firom a 
space service's advertiseident in order to access the space. A client of a space m^ itself be a service provide 
seekmg to advertise in that space or modify an existing advertisement Or a client of a space may be an ^plication 

35 seekmg to access a service or content listed by the space. Thus, spaces may provide catalysts for tiie mtcraction 
between cUents and services in the distributed computing aiwomnent 

A space may be a collection of named advertisements. In one embodiment, naming an advertisement is the 
process of associating a name string with an advertisement The association may take place \xpon storing an 
advertisement in a space. Removing an advertisement from a space disassociates the name tcom the advertisement 

40 A space may be created with a single root advertisement that describes the space itself Additional advertisements 
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may be added to a space. An advertisement's name may locate the advertisement wWiin tiie space, including 
specifying any necessary graphing information such as a hierarchy of names. In a preferred embodnneht,.the .. 
distributed computing environment , does not dictate the structure of a space. That is, spaces may be structured as, 
for example, a flat un-related set of advertisements or a graph of related advertisements (e.g. commercial database). 
Since, in a preferred embodiment, the distributed computing environment does not dictate how a space actually 
stores, its content, spaces may be supported by smaD to large devicesi For example, a single space may be tailored 
to fit on smaU devices, such as PDAs; More advanced spaces may be implemented on large severs employing lar^^ 
commercial databases. 

As mentioned above, a space may contam advertisements for services in the distributed computing 
environment An advertisement may provide a mechanism for addressing and accessmg services and/or content 
within the distributed computing environment An advertisement msy spedfy a URI for a service. In some 
embodiments, tibe tJRI may allow for the service to be accessible over the Internet An advertisement mary also . 
include an XML schema for the service. The XML schema may specify a set of messages tiiat cUents of tiie service 
may seiid to tiie service to invoke functionality of the service. The XML schema m^ define the client-service 
15 interface. Togetiier, the URI and the XML specified m an advertisement may indicate how to address and access tiie 
service. Both the URI and schema may be provided in XML as an advertisement in a sp^ Thus, a mechanism for 
addressing and accessing a service in a distributed computing environment may be published as an advertisement in 
a space. Clients may discover a space and then lookup individual advertisement for services or content 

Figure 16 illustrates advertisement structure according to one embodiment An advertisement 500, like 
20 other XML documents, may mclude a series of hierarchicaUy arranged elements 502. Each element 502 may 
include its data or additional elements. An element may also have attributes 504. Attributes may be nam^value 
strmg pairs. Attributes may store meta-data. which may fecilitate describmg the data withm the element 

In some embodiments, an advertisement may exist in different distinct states. One such state may be a 
drafted state. In one embodiment, advertisements may initially be constructed in a drafted state that exists outside 
25 the bounds of a space. The creator of an advertisement may construct it m a variety of w^, including using an 
XML editor. Access to elements and attributes in die drafted state may be at the raw data and meta-data levels using 
any suitable means. TypicaUy, events are not produced for changes made to advertisements in tiie drafted state. 
Tberefore, the creator of tiie advertisement may be free to add, change, or delete elements as weU as. to achieve tiie 
d^ired attribute set, and then publish the advertisement for the rest of tiie distributed computing environment to see. 
30 In one embodiment, anotiier possible state for advertisements is a published state. Advertisements may 

move to the published state when mserted into a space. Once tiie advertisement is in a space, interested cUcmts, and 
services m^ locate it, e.g. using its name and/or its elements as search criteria. For exanq)le, seardi critCTia may be 
specified as an XML template document tiiat may be compared (e.g. by tiie space service) witii tiie advertisements m 
tiie space. Published advertisements may represent "on-line'' services ready fin: cUents to use. Tte message address 
35 (URI) of tiie service m^ be stored as an element m tiie advertisament Advertisements that are removed fi-om tiie 
space may transition back to tiie drafted state where tiiey may be discarded or held. Removal may generate an event 
so interested listeners may be made aware of tiie change. Message gates are fypically created from published 
advertisements. 

In one embodiment, yet anotiier possible state for advertisements is a p«sistent archived state. An archival 
40 procedure may turn a Uve published advertisement into a stream of bytes tfiat m^ be persistentiy stored for later 
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reconstruction. Archived advertisements may be sent (e.g. in their raw XML form) from flie space to an archival 
service. The UBI for an advertisement's archival service may be stored as an element in the advertisement XML 
may provide a fonnat for storing and retrieving advertisements and representing the state of advertisement elements 
sufficient to recoiistruct toe advertisement object(s). Advertisements may be stored in other formals as well. 

5 depending on archival service inqjlementaticm. The process of nwkmg a published advertisement persistent may 
prepare die advertisement for the persistent archived state. Persistent advertisements may be stored (e.g. by an 
archival service) for fatnre use in a persistent storage location such as a file or a database. A space toough flie 
archival procedure may enable advertisements to be stored, howevCT the space does not necessarity play a role in. 
how persisted advertisement entries are actually stored. How persisted advertisements are stored may be determined 

10 by the advertisement's archival service. Typically, no. events are generated on behalf of archived advertisements. 
Also, changes inay not be allowed for advertisements in the perastent arrfiived state. 

Advertisements may be archived and removed or just ardiived. If an advertisement is archived wifliout 
removing it from the space, the space will store a shadow version of the advertisement Access to an archived 
service may cause the advertisemenUo 'Tauft-m" from its persistent baddng store on demm^ This feature m^ 

15 allow advertisements to be filled, from LDAP (Lightweight Directory Access Protocol) entries for example, on 
demand. 

Figure 17 illustrates one example of advCTtisement state transitions tbat an advertisement way undeigo 
during its lifetime. First, an advertisement may be constructed, as indicated at 1. During construction, the 
advertisement is in the drafted state. Then, the advertisement may be inserted in a space, as indicted at 2. Ttie 

20 advertisementmaybe inserted asapublished parent. Tlie advertisement is in the published state after bemg inserted 
in a space. An event (e.g. AdvInserfEvent) may be generated when the advertisement is inserted in the space. 
Events are more fiiUy discussed below. Tbe advertisement may be archived and made persistent, as indicated at 3. 
which may transition the advertisement to the persistent archived state. An advertisement may also be published 
from the persistent archive state, as indicated at 4. An advertisement may be removed from a space and transition 

25 back to the drafted state, as indicated at 5, An event (e.g. AdvRemoveEvent) may be generated i^en the 
advertisement is removed. 

In one embodiment, the archived, persistent state is not used. In this embodiment, state changes 3 and 4 
also are not used. Inthis embodiment, an advertisement is either in the drafted state or in the publ^^^ 

Advertisements stored in a space may have Ihe foUowiag standardized elements and/or attributes: version 
30 (may be an element), creation date (may be an attribute), modification date (may be an attribute), implementation 
service UW (may be an element), and/or persistence arcMval ser^ 

A space itself is typically a service, A space service inay provide tiie abm 
tiiie space, which may include searching the space by type of advertisements. A space service m^ also provide 
faciUties to read advertisements, write (publish) advertisements, aid take (remove) advertisements. A space may 
35 also provide the abQity to subscribe for space event notification messages. Some spaces m^ provide extended 
facilities, such as feciUties to navigate space relationship graph by position; read, write or take advertisement 
elements; r^ write or take advertisement attributes; and subscribe for advertisement event notification messages. 
Space feciHties are described in more detafl below. A space's c^abilities are embodied in a space advertisement's 
' message schema.* From the message schema, space address, and authentication credential, a client message gate may 
40 be created to access the space and its facilities. 
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Spaces and all advertisements withm a space may be addressed using URIs. In one embodiment, space and 
advertisement names may follow URL naming conventions. The use of URIs, e.g. URLs, for addressing spaces may 
allow spaces to be addressable throughout the Internet, in some embodiments. 

the space message recipient (a space service) may be specified using a URI which may have been received 

5 ma service advertisement for the space. The URI may include a protocol, host, port number, and name. The 
protocol may name the protocol that may be used to move messages between clients and the space (reliable or 
un-reliable sockets, for example). The host and port number may be protocol dependent IDs. The name may be the 
space name followed by advertisement, element and/or attribute name. In one embodhnent, a pathnanie may be 
used to identify an advertisement in a space. Pathnames m^ be either absolute or relative. Absolute pathnames 

10 name the space as well as an advertisement Relative pathnames are relative a designated advertisement within an 
assumed space. In one embcwiiment, the syntax rules governing the construction of pathnames is &at of Ihe URI 
(Uniform Resource Identifier). In that embodbnent, advertisement and space names therefore joay not contain any 
URI reserved characters or sequences of characters. Pathnames to elements and attributes may also be specified 
using a URI. In general, element and attribute names may be £q)pended to the pathname of an advertisement, such 

15 as: 

http:/j5ava.sun.coni/spacename/advertisement/element/attnb 

In one embodiment, the distributed computing raivironment may include a mechanism that allows a client 
to discover the URI of a space but restricts access to tihe service advertisement for the space. In one embodiment, 
rather than returning the fvOl advertisement to the space, the URI of the space and the URI of an authentication 
20 service for the space may be returned. In order for the client to access the documents or services advertised m the 
space, the client first may authenticate itself to the authentication service at the URI provided in the return message. 
. The authentication service may then retum an authentication credential that may allow the client partial or fiill 
access to the space. When the client receives the authentication credential, the client may attempt to connect to the 
space to access the documents or service advertisements in the space. 

25 . The distributed computing environment may provide a mechanism or mechanisms that may enable a client 

to connect to a space. Embodiments of a connection mechanism may provide for client-space addressing, client 
authorization, security, leasing, client capabilities determination, and client-space connection management A 
client-space connection may be referred to as a session. In one embodiment, a session may be assigned a unique 
session identification number (session ID). The session ED may uniquely identify a client-space connection. In one 

30 embodiment, a session lease mechanism may be used to transparently gsrbage collect the session if the client does 
notrenew the lease. . * 

The following is an example of usmg such a connection mechanism according to one embodiment A 
client may obtain an authentication credential. In one embodiment, the space may provide an authentication service 
in response to a client's request for access to the space. The client may obtam the authentication crederitial throiigh 

35 the authentication service. When the client receives the auflientication credential, the client may initiate a 
connection to the space by sendmg a connection request inessage. In one embodiment, the connection request 
message may include the URI address of the space service, tiie authentication credential for the client and 
information about the connection lease the client is requesting. After the space receives the connection request 
message, the space may validate the message. In one embodiment, an XML schema may be used to validate the 

40 message. The client may ttien be authenticated using the auftientication credentiaL In one embodbnent, the 
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infonnation received in the connection request message may be used to detennine the capabilities of the client to use 
the space. In one embodiment, each cUent of a space may be assigned its own set of capabilities for using the space. 
In one embodiment, an access control list (ACL) that may include capabiHty information about one or more clients 
of the space may be used m client capabilities determination. In one embodiment, the information received in the 
connection request message may be used to look up the client's cs^bilities in the ACL. 

After au&enticating the client and determming the client's capabilities, the coiinection lease to grant the 
client may be determmed. After the lease is determined, the structure for maintaming the cUent-space connection 
may be generated, A session ID for the connection may be generated. In one embodiment, each client-space 
connection may be assigned a unique session ID. In one embodiment, an activation space may be created and 
assigned to, or alternatively a pre-existing activation space may be assigned to, Ae client-5pace session. In one 
embodraient, an activation space may be used to store results of services for ^e client y/bax using the q)ace. In one 
embodiment, a client's capabilities may be used to determine if an activation space is to be created for the client 
For example, a client may not have capabilities to access an activation space to store and retrieve results. A message 
or messages may be sent to tiie client informing the client that the connection has been established. The message or 
messages may mclude the session ID and information about tiie lease. Tbe client m^ then use the space including, 
but not limited to: advertisement lookup, advertisement registering, and advertisement retrievaL In one 
embodiment; he connection may remain open until the allocated lease expires or until the client sends a message 
requesting lease cancellation to tiie space. In one embodiment, the client may be responsible for renewing the lease 
before tiie lease expires. If the lease expires before tiie client renews tiie lease, the connection may be dropped, 
causing tiie client to lose the connection to tiie space. In one embodiment, to reconnect, the client may be required 
to repeat the cormection procedme. 

In one embodiment, a client of a space may obtam a space's advertisement several different ways. Some of 
tiie ways a cUent may obtain a space's advertisement are illustrated in Figure 18. For example, a space discovery 
protocol may be provided as part of tiie distributed computing environment Space discovery is a protocol a client 
or service may use to find a space. A listener agent 202 may be configured associated witii one or more spaces to 
listen for discovery requests. The discovery listener agent 202 may listen on various network interfeces, and may 
receive eitiier broadcast requests or unicast requests (at tiie URI of tiie agent) from cUents 200a looking for a 
space(s). The listener agent 202 tiien responds witii tiie service advertisement(s) or URIs for tiie service 
advertisements of the requested space(s), hi one embodiment, tiie Ustener agent is, m general, separate from the 
space, because its functionality is orthogonal to tiie fimctionality of a space service. However, tiie listener agent 
may be implemented on the same device or a different device as a space service. 

hi one embodiment, the discovery protocol may be a service advertised m a default space. A client may 
instantiate tiie discovery protocol fix>m tiie client's default space m order to discover additional spaces. The 
discovery protocol may be pre-registered witii a client's default space. Altemativefy, tiie discovery protocol may 
register itself witii the default space by placmg an advertisement in tiiat space, eg., when a client cormccts to a local 
network serviced by the discovery service. 

In one embodhnent, tiie space discovery protocol may be mapped to underlying device discovery protocols 
. for otiier platforms, such as SLP, Jmi, UPnP, etc. Ibus, a cUent may use tiie discovery protocol of the distributed 
computing environment to find services in otiier environments. A bridge to tiiese otiier environments may be 
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provided, and advertisements provided to services in these other environments so that cHents of the distnbuted 
computmg environment descnT)ed herein may access them. Refer to the 5nrf^^ 

For each advertised discovery protocol, the distributed computing environment may create a subsequent 
results space to hold the results of the discovery protocol, hi one embodiment, space services in the distibuted 
computing environment may use the Multicast Announcement Protocol (multicast UDP) to announce themselves on 
a LAN. A listener agent .may record this mfonnation. A device (either a client or service) may use the Multicast 
Request Protocol(multicast UDP) to initiate discoveiyofaspace manager. In one embodiment, the space managers 
. respond wth mfomatioh indicating the URI Alternatively, a listener agent may respond . 

for multiple spaces. The discovery response may also mclude a short string timt labels tiie each space ^^^^ 
from keywords of the space), and mformation that can be used to set up a TCP connection, for example, vwth each 
space manager to perform operations on die respective space. Since tiie requesting device may receive responses 
from more tiian one space manager (or multiple space listings from a listener agent), this mformation may help tiie 
client select which space it wishes to coxmect to. 

hi addition to tiie multicast discovery described above, the discovery service may also perform discovery 
usmg unicast messaging (e.g. over TCP) that can be used to discover a space manager at a known address on tiie 
network (e.g. the Internet, otiier WAN, LAN, etc). The unicast discovery message may include a request for a space 
service at a known URI to iHX)vide its service advertisement Hie multicast and unicast discovery protocols are 
defined at die message level, and thus may be used regardless of whether the devices participating m the discovery 
support Java or any other particular language, 
) .The discovery protocol may fecilitate the proliferation of clients independentiy of the proliferation of 

server content that supports those cUents within the distributed computing environment For example, a rnobile 
. client may have its mitial default space built into its local platfomL In addition to local services advertised in the 
default space, the mobile cHent may have services that search for additional spaces, such as a service to access the 
discovery protocol or a service to access space search eiigmes. 
5 In one embodunent, the distributed computmg environment space discov^y protocol may defirie a set of 

XML messages and their responses that may allow clients to: 

• Broadcast protocol-defined space discovery messages on their network interfaces. 

• Receive fmm Usteners XML messages describing candidate spaces that tiiose listeners 
represent 

10 . - iSelect one of diose discovered spaces as defeult, without the cHent needing to know die 
address of the selected space. 
o Obtain information on the selected space, such as its address, so die ctien^^ 

same space via means outside of the. discovery protocol (usefiil if later the client wants to 
access a space which is no longer local, but w^ch stiU is of interest to the client). 
35 . In some embodhnents, the multicast and unicast discovery protocols may require an IP ne 

tiiese discovery protocob meet the needs of devices tiiat are IP network capable, tiiere are many devices feat may 
not be directiy supported by these discovery protocols. To meet die needs of such devices in discovwing spaces in 
the distributed conq)uting environment, a pre-discovery protocol The 
■ pre-discovery protocol may include tiie device sendmg a message on a non-IP network interfece requesting a 
40 network agent The network agent may set up a connection between itself and tiie device. Once the connection 
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between device and agent is set up, the ageiA participates in the discoveiy protocol on IP networks pn behalf of the 
device for which: it serves as. agent The netvyork agent may also provide an interface for the device to the 
distributed computing environment in general. For example, gates may be constructed in the agent on behalf of the 
device for lumiing services advertised in discovered spaces. See fte ^rwfewig sectioa 
5 Another way that cUents may locate spaces in the distn^uted computing environment is by adverts 

a space. in another space. A space is a service, thereforeso. like any other service, it can be advertised.in another 
space. As shown in Figure 18, a client 200b may find an advertisement 206 m a first space 204a for a second space 
. 204b. Space 204b may in turn mclude advertisements to additional spaces. Because a service (in^)lementing a: 
space) may also act as a client, spaces may exchange advertisements or chain together to provide a federation of 
10 spaces, as Ulustiated in Figure 19. Any number of spaces may be . inchided in the distributed computing 
environment Tbc number and topology of spaces n^ be impleineirtation dependent For example, spaces 
hnplemented on an IP network might each correspond to a different sataet 

A third way a clientmay locate a space is through running a service 208, as shown m Figure 18. A setvice 

208 may be run whidi letams as its results flie service advertisements of space services. Since service 
15 advertisements are XML documents and since the distributed computing environment may inchide the Intianet, 
service 208 may be a Web-based search tool An exani|)le of such a service is the space look-i?> service described 
in conjunction with Figure 4. In one embodiment, spaces within flie distributed confuting envhomnent may be 
implemented as Web pages. Each Web page space may include a keyword fliat may be searched upon to identify 
the Web page as a space in tt»e distributed computing enviromnent The space may include other seardiable 
20 keywords as weU to fiirther define die space. A cUent may connect to a search service 208 and suppty keywords to 
the search service in the form of XML messages. The seardi service may receive the keywords fixim the cUent and 
feed the keywords to an Internet search engine, which may be a conventional or third-party seardi engine. The 
search service may return the lesutts fiom the Internet search engine to the cUent. either directly as XML m«!sages 
or by reference to a insults space. The results may be the URIs of spaces matchmg the search request 
25 Alternatively, the search service may contact spaces identified by the search, obtain the service advertisement for 
each such space, and return the space service advertisements to the client, either directly as XML messages or by 
reference to a results space. The cUent may then select a space from the search results and construct agate (by itself 
or through a proxy) to access the selected space. Once the selected space is accessed, the cUent may look up service 
advertisements within that space. \Aich may lead to additional spaces. 
30 As described above, a space may be an XML^ased Website, and as such may be searched via hitemet 

Web search mechanisms. A q>ace may mclude Internet seardiable keywords. Some devices, sudi as smaD cUait 
devices, may not support an totemet browser. However, sudi devices may still perform Internet seardies for spaces 
wiflim the distributed computing envhxmmait A device m^ have a program that ac«^>ts strings of keywords, 
whidi may be sent to a proxy program on a server (e.g. a seardi service). The proxy may send the strings to a 
35 browser-based seardi feciKty(e.g. an internet sdirdifedlity) to perform die search. The proxy may receive the 
output of the search and parse it into strings (e.g. XML strings) representing each URI for the seardi results and 
send the response strings back to the cUent Thus, a cUent may lo«te spaces through the Inh^ 
support a program such as a Web brt)wser: More capable devices m^ avoid tiie use of a pro^qr and midate an 
Internet-based search service directly. 
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A fourth way a client may locate a space is by obtaining or receiving infonnation about a newly created 
empty space or a spawned space when an existing space is spawned An existing space may mclude an interfece for 
spawning an empty space with the same functionality (e.g. same XML schema) as the space from which it is 
spawned. Spawning of spaces is further described below. 

Once a client of a space finds the advertisement of a space service, tiaat client of the space may run the 
space service, as it would any other service. Note that the client of the space service may be another service (e.g. a 
service seeking to advertise in the space). In one embodiment, as ilhistrated m Figure 20, to run a space service, the 
client of the space may first run an authentication service for the space to obtam an authentication credential, as 
indicated at 300. The authentication service may be specified in the service advertisement of the space service. Ibe 
client of the space uses the authentication credential, the XML schema of the space (from spacers service 
advertisement), and tiie XJRI of the space (from space's service advertisement) to construct a gate for Ae space, as 
indicated at 302. The client of tiie space m^ thai run the space service by using the gate to send messages to Ifae 
space service. A first such message is indicated at 304. 

For embodiments employing authentication, when the space service receives tiie first message firom the 
client, with the authentication credential embedded, the space service uses the same authentication service (specified 
in the service advertisement of the space service) to authenticate the cliait, tiius establishing its identity, as indicated 
at 306. The space service may determine the client's capabilities and bind them to the authentication credential, as 
indicated at 308. 

As indicated at 3 10, a client of a space may run various space fecilities by sending messages to the spiace 
service. In one embodiment, when a client of a space sends a request to ttie space service, it passes its authentication 
credential in that request, so the space service can check the request against the client's specific capabilities. 

Each space is typically a service and may have an XML schema defining the core functionality of the space 
service. The XML schema may specify the client mterfece to die space service. In one embodiment, all space 
services may provide a base-level of space-related messages. The base-level space functionality may be tiie basic 
space functionality that is capable of being used by most clients, includmg small devices such as PDAs. It may be 
desirable to provide for additional functionality, e.g. for more advanced clients. Extensions to the base-level space 
may be accomplished by adding more messages to the XML schema that advertises the space. For example, in one 
embodunent, the base-level messages do not impose any relationship graph upon the advertisements. Messages, for 
example, to traverse a hierarchy of advertisernents may be a space extension. Such additional fimctionality may be 
provided through one or more extended XML space schemas or schema extensions for a space. The extaidcd 
schemas may include the base schema so that clients of an extended space may still access the space as abase space. 

In one embodirhent, a base space service may provide a transient repository of XML documents (e.g. 
advertisements of services, results of rurming services). However, a base space service in one embodiment not 
provide for advanced fecilities to support persistence of space content, navigation or creation of space structure (e.g. 
hierarchy), and a transactional model. A mechanism for supporting persistence, hierardty, and/or transactions is by 
extending tiie XML schema. Since extended spaces stiU inchide liie base XML schema, clients may still treat 
extended spaces as base spaces, when just tiie base space fimctionality is all that is need or all that can be siq>ported. 

In one embodunent, the base space may be transient The base .space may be acceptable for many 
purposes. Service providers may register then: Srcrvices m various spaces. In one embodiment, services must 
continuously renew leases on the publishing of infonnation in tiie spaces. By this nature, the services 
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advertisements may be transient in that they may often be rebuilt and/or reconfirmed. However, it m^ be desirable 
to provide for some persistence in a space. For example, a space that has results may provide some persistence for 
users that want to be sure that results are not lost for some time. In one embodiment, persistence may be provided 
for by specifying a space interfece where the client may control which objects in the space are backed by a persistent 
store and manage the maintenance of that persistence store. The persistence interfece may be specified with 
extended XML schema for the space defining the interfeces for persistence. 

In one embodiment, a base space may provide an interfece where an XML document may be added to a 
space and identified by a string. The base space may not provide any hierarchy for the various so named XML 
documerits in the space. In embodiments where hierarchy support is desired, additional interfeces may be defined 
(extending the XML schema) where the user can specify a hierarchy. Other interfeces n^ be specified to navigate 
the hierarchy or navigate a relationship graph by position. Howcvct, oilier users may stffl use the base space 
interfeces to access those same documents, without any hierarchy. Interfeces for o&er space structure may be 
provided for as well in extended space schemas. 

Extended XML space interfaces may also be provided for space transaction models. For example, an 
extended space XML schema may be provided specifying an interfece for ACID transactions. AGIO is an acronym 
used to describe four properties of an enterprise-level transaction- ACID stands for Atomicity, Consistency, 
Isolation, and Durability. Atomicity means that a transaction should be done €s: undone completely. In tiie event of 
a feilure, all operations and procedures should be undone, and all data should roUback to its previous state. 
Consistency means that a transaction should transform a system fi-om one consistent state to another consistent state. 
Isolation means that each transaction should happen independently of other transactions occurring at the same time. 
Durability means that completed transactions should remain permanent, e.g. even during system faihire. Other 
tr^isaction models m^ also be specified in extended space schemas. 

Extended space sdiemas may be XML documents that specify the message interfece (e.g. XML messages) 
for using extended space features, fimctionaUty or feciiities. A space may have a base schema and multiple 
extended schemas. This may fecUitate provided different levels of service to different clients depending upon the 
client authenticatioa 

Besides extensions for space persistence, structure, and transactions, other space extensions niay also be 
specified as desired. For example, extensions may be provided to manipulate advertisements at the elenient or 
attribute level: read, write or take advertisement elements; read, write or take advertisement attributes; and subscribe 
for advertisement event notification messages. A space may provide virtuaUy any number of feciiities and arrange 
tiiem in base and extended schemas as desired. In one embodiment, all base spaces must provide fin- advertisement 
reading, writmg, taking, and lookujp facilities, and space event subscriptions. 

Various space feciiities may be provided, hi. some embodbnents, a fecility may be provided for the 
establishment of a session with the space. In one sudi embodiment, the r^st of the space fimctionality is not 
available until this is done. In other embodiments, the notion of a session is not provided for, or is optional and/or 
implementation dependent 

Another space facility may be to add or remove a service advertisement to or fix)m the space. A space 
facility may also be provided for addmg or removing an XML document (not an advertisement, but pediaps a result 
' in a space). The space service m^ check for uniqueness of an item before aUowing tiie addition of the item.' For 
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example, each item added to Ae space may be associated with a user-specified string tiiat identifies the item and that 

may be used to check for the uniqueness of the item. 

In one embodiment, a cUent may request a listing, tree or otiier representation of all services advertised in 

the space. The user then may scroll or maneuver through the advertisements and select the desired service. A space 
5 may also provide a look-up fecility that allows a client to search for a service, by providing keywords or string 

names. In one erabodhnent, a space facility may provide a mechanism to look up a space entry that has been added 

todiespace. TheTook up faciUty may search by string to match for name, or wildcat The 

look up facility may return multiple entries firom which the client may select one or perform a further mirov«ng. 

search. In one embodhnent, the look-up fecUity may provide a mechanism to locate a service advertisement 
10 matchmgaparticularXMLschema. ThecHentmay indicate a particular XML schema, or part of a particulars^ 

to be seaidied for within the space. Thus, a service may be searched for witiiin a space acamih^ 

fimctionality. 

Another space fecility that may be provided in the distributed computing environment is a mechanism that 
allows services and cUents to find transient documents based upon a typing model such as XML. The mechanism 
15 may be a general-purpose, typed document lookup mechanism. In one embodiment, the lockup medianism msy be 
based npon XML. The lookup mechanism ma^r aBow cUents and services to find documents in general, inching 
services through service advertisements. 

hi one embodiment, a space lookup and response message pair may be used to allow clients and services to 
find XML documents stored withm a network transient document store (space). The space may be a document 
20 space used to store a variety of documents.. In one embodhnent, the documents are XML documents or non-XML 
documents encapsulated m XML. Spaces are fiirther described else>^ere herein. The lookup messages may. work 
on any kind of XML document stored m the space, includmg service advertisements and device driver 
advertisements. In one embodhnent, a client (which may be anotiier service) may use a discovery mechanism as 
described elsewhere to find one or more document spaces. Then, the cUent may use space lookup messages to 
25 locate documents stored in the space. 

The distributed computing enviroiiment may. mclude a mechanism that aUows services and clients to 
subscribe to and receive events about the pubUcation of XML documents. Events may include the publication of 
and removal of XML documents to and firom a transient XML document repository such as a space. In one 
embodiment, an event may be an XML document that refers to another XML document 
30 In one embodhnent, a space event subscription and response message pair may be used to allow cUaits and 

services to subscribe for events regardmg documents tiiat are added to or removed firom a space. In one 
embodhnent, an event subscription may be leased usmg the leasmg mechanisms described elsewhere herem. In one 
embodiment, a subscription may be canceUed Mdben the lease is cancelled or exphes. In one embodiment, renewing 
the lease to the subscription may renew a subscrqitiorL 
35 In one embodhnent, an event subscription message may include an XML schema that m^ be 

document matchmg mechanism. Documents that match the schema may be covered by the subscription, In one 
embodhnent, any document added to a space and that matches the XML schema may g^erate a space event 
message. . 

A space fecifity may also be' provided to which a client may register (or unregister) to obtam notification 
40 when somethmg is added to or removed firom tiie space. A space may contain transient content, reflecting services 
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that at added and removed from the space. A mechanism may be provided to notify a client when a.service becomes 
available or becomes unavailable, for example. A client may register with an event service to obtain such 
notification. In one embodiment, a client may register to.be notified ^/Aea a service having a name matching a 
specified string or a schema matching a specified schema (or schema portion) is added or deleted from the space. 
5 . Thus, a query to register with the space event notification feciUty m^be the same as or simflar to that of the service 

lookup facility described above. 

When a cUent of a space subscribes to be notified ^^*en an XML document(s) (e.g. serwce advertise 

is added or removed from the space, fte client may obtain a lease rai this subscrqrtion to notifications. The lease 
may aUow ttie space service to know whetha- to continue sending notifications to a particular cUenL For example, a 
10 lease to the notification feciHty m^ expire after an amount of time if not renewed. Note that a lease may not be 
. required while a cUeit has established an active session with a spaca Onoe, a cUen^ 

session wifli a space, tiie client may continue to receive event notifications according to its event subscriptions as 
long as its coirespondmg leases remain active. Refer to the Leases sectiwi below. 

A client may subscribe to different types of events. Examples are a service advertisement being added or 
15 removed from a space, as described above. A client may also be notified when results from a service initiated by the 
cUent (or by someone else) are put m a space. For example. fl»e cUent and the service may mutually select a name 
for referring to tiie lesdts of the service. The cUent may register with the space service to wUch the results are 

posted or advertised to receive an event when a result referenced by tiie selected nane is added to the space. 

A space generate different types of events to which a cUent may subscribe. As tiie composition of a 
20 space changes, events m^ be produced to those cUents and services fliat have subscrfljed for such events. In one 
embodiment, there may be two major space event categories, those that pertam to ttie space (insertion and removal 

of advertisements), and those used that indicate changes to an advertisement (adding, removmg, changing an 
element or attribute); Which events are supported may be indicated in flie XML message schema for the space. 

The followmg events are examples of events that may be produced by a space service to indicate a space or 
25 advertisement event 



Table 1 



Event Name 


Type 


Meaning 


Advertisement 
Insertion Event 


AdvInsertEvent 


New advertisement has been inserted 
into a space 


Advertiseinent 
Removal Event 


AdvRemoveEvent 


Existing advertisement has been 
removed from a space 


Advertisement 
Element Insertion Event 


AdvElementlosertEvent 


A new element has been added to an 
advertisement 


Advertisement 
Element Removal Event 


AdvElementRemoveEvent 


Existing element has been removed 
from an advertisement 


Advertisement 
Element Change Event 


AdvElementChangeEveat 


Existing element has been changed in 
an advertisement 
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Advertisement Element 
Attribute Insertion Event 


AdvElementAttributelnsert 
Event 


A new attribute has been added to an 
element 


Advertisement Element 
Attribute Removal Event 


AdvElementAttribnteRemove 
Event 


Existing attribute has been removed 
from an element 


Advertisement Element 
Attribute Change Event 


AdvElementAttributeChange 
Event 


Existing iattribute has been changed in 
an element 



Events may be typed. In some embodmaents, the event facilities supported by spaces may allow for event . 
listeners to take advantage of, e.g., Java class (or XML types) hierarchies. For example, by listening for 
AdvElementEvent, the listener will receive events of type AdvElementEvent arid all of its sub-classes (XML types). 
Hius, for this example aU events pertaimng to element changes (thou^ not advertisement insertion and removal) are 
received. 

By way of further example, subscribing to or listening for a top-level event class or type, e.g. SpaceEvent, 
will result in the reception of all space events. Event class types may be distinguished via, for example, the Java 
//w/a«ceo/operator or the XML typing system. 

An event may include a URI to the affected advertisement or element For example, AdvertisementEvent 
and all its sub-classes may contain a reference (e.g. URI or URL) to Ihe affected advertisement AdvEliementEvent 
and its subclasses may be examined for the name of the affected element The previous element value (URI or 
URL), may be available, for example, from AdvElementRemoveEvent and AdvElementValueChangeEvent 

A space event type hierarchy for one embodiment is illustrated in Figure 21 . Types may be defined in XML 
and usable in Java or any other suitable object-oriented language such as C-H-. 

A space may provide a facility for a client to mstantiate a service advertised in the space. Service 
instantiation is the initialiTation done that allows a client to be able to run a service. On embodiment of service 
instantiation is illustrated in Figure 22. To instantiate a service, a client may first select one of the service 
advertisements published in the space, as mdicated at 320. The client may use the various facilities, such as the look 
up fecility, provided by the'space to look up the various advertisements in the space. Then the client may request the 
space to instantiate the service, as mdicated at 322. 

In one embodunent, service mstantiation may include the following actions. After the client requests the 
space service to mstantiate the selected service, as indicated at 322, tiie space service may then verify the client is 
allowed to instantiate tiie requested service, as mdicated at 324. The space service may perform this verification by 
examining an authentication credential included in the client's message. The authentication credential is tfie 
credeintial the client received when it established a session wth tibe space service. The space service m^. verify if 
the client is allowed to instantiate the requested service according to the client's authenticiation credential and 
capabilities indicated for that client See the Auftientication and Security section herein. 

Assuming the client is authorized, the space service may also obtain a lease on the swvice advertisement 
for the client wife the lease request time specified by the client, as indicated at 326. Leases are further discussed 
below. The space service may then send a message to the client which mcludes the allocated lease and tfie service 
• advertisement of the service, as indicated at 328. In one embodiment, the client may run an authentication service 
specified in the service advertisement and obtain an authentication credential, as mdicated at 330. See the 
Authentication and Security section herein for more mformation on an authentication service. Next, as indicated at 
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332, the client may construct a gate for the service (for example, using the aalhentication credential and the XML 
sctema and service URI ftom the advertisement). Refer to the Gates section herein. THe above described 
communication between the client and space service is performed using the XML messaging of the distributed., 
computing enviromnent. ITie cUent may then nm fte service using the constructed gate and XML messaging. The 
5 servicemaysimilarlyconstnictaservicegateforXMLmessagecommunicationwth^^ 

To summarize, an example use of a space is discussed as foUows. A cUent may access (e.g, 
space service. (A service may act as a client for the purpose of accessing or otherwise using a space.) Tie space 
. service may store one or more service advertisements and/or other content in a space, and each of the service 
advertisements may include information ivhich is usable to access and execute a corresponding service. The space 
10 service may mchide a schema which specifies one or more messages usable to invoke fimctions of the space service. 
For example, the schema may specify methods for .wading advertisements from the space and publishing 
advertisements in the space. The schema and service advertisements may be expressed in an obje^^ 
language such as extensible Markup Language (XML). In accessing the space service, the client may send 
information such as an XML message (as specified m the schema) to the space sendee at an Intemet address. In 
15 accessing the space service, the client may search the one or more service advertisements stored in the space. The 
cUent may select one of the service advertisements from the space. In one embodiment, the client may send an 
instandation request to the space after selecting the desiied service advertisements from the space. A lease may be 
obtained for the desired service, and the lease and the selected service advertisement may be sent by the space 
service to the cUent The cUent may then construct a gate for access to the desired service. The desired serv^^ 

20 be executed on behalf of die client 

Another fadlity. provided by a space service may be the spawning or creation of an empty space. This 
space fecility may allow a cUent (which may be a service to another cUent) to dynamically create a new space: In 
one embodiment, this space fecility may include an interfece for spawning an empty space with the same 
fimctiomdity (same XML schema or extended schema) as the space from which it is spawned. This fecility may be 
25 usefid for generating (e.g. dynamically) spaces for results. For example, a cUent may spawn a space a recpiest a 
service to place results or advertise results in the spawned space. The client may pass the spawned space URI 
. and/or auflientication credential to the service. Or a service may spawn a space for results and pass the spawned 
space URI and/or authentication credential to.the client In some embodiments, once a space is spawned. H may be 
discovered just like other spaces using one or more of the space discovery mechanisms desc^^ 
30 By using a mechanism in which a space may be created via an interfece in another space (eg. a space 

spawning facmty). new spaces may be created efficitmtly. For example, in one emibodiment. storage for the 
spawned space may be aUocated using the same facility used, by the ciigmal space for storage. Also, a spawned 
space miv share a common service fecility wi* its original (or panmt) space. For exampl^^ 
assignedtothenewspace. In one embodhnent. the new UM may be a redirection to a common space fecilrty shared 
35 wrlhtheorigmalspace.Thns.anewlyspawnedspacemayusethesameorsomeoft^^ 
the original space. 

Space feciUties may ako include security admhustration, for example, to update the ym^ 
poUcies of the space, and o&er admmistratiVe fecilities. For example, ihe .mmiber and age of advertisements may be 
controlled and monitored by a root space service. Old advertisements may be collected and disposed. See..e.B,lhe 
Leases section herein for when an advertisement may be considered old The service implementing the space.may 
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be under the control of an administrator. Ihe administrator may set policy in a service dependent maimer; Space 
facilities may also include a fecility to delete an empty space. 

Certain spaces inay inchde fecilities or services to further support the prolif^ 
as mobile clients. For example, services in spaces that a mobile client may discover, e.g. via the discqveiy protocol, 
may provide support for mobile clients, such as: 

• Assigning and admimstering temporary network addresses for the client 

Proxying message passing fw the client . 

Providing search facilities fOT additional spaces. For example, a service aUow a 

client to specify keyv^-ords thfou^ a simple interface. Hie service then uses the keywords in 
conjunction widi Web search engines to search for spaces on the Web, as further descn^ 
herein. In other embodiments, a seardi service may constrain clients to searching only a fisw 
siq)ported spaces wifliin flie distributed computiiig environment 
As mentioned earUer (see Figure 9 and accompanying text), spaces may provide a convenient mechanism 
for storing results fiom a service run by a cUent Using a space for results may allow a small client to receive in 
pieces the results of lumiing a service. Some services may generate a large amount of results. By using a space Id 
store the results fiom a service, clients that do not have the resources to receive the fiill results at once may stffl use 
the service. Moreover, by usmg a space to store results, a service running on a fest busy seiver may be fieed fi^ 
interacting directiy with a slow client when retummg large results. Tbus, the service may be fieed sooner for use by 
Other clients. 

20 A space may provide a conyeruent mechanism for accessing a result by different cUenb and/or at di 

times. For example, a client may not be able to use the entire result, but a user may want to access the rest of the 
• result later using another cUent that can access it For example, the result could be stock quote information, showing 
the current price of a stock (accessible by a PDA), and showing a chart of stock prices (accessible by a laptop later). 
Also, using a space in the distributed computing environment for results may allow a client to feed tiie result of one 

25 servi« into another service, without tiie necessity of downloading the result first For example, m the case of the 
stock quote information above, the PDA could feed the chart into another service, whicb prints the chart, without the 
PDA having to download flie chart itself Hius, a results space may provide a mechanism for a client to pass to 
another client or service witiiout flie client having to handle or receive fee results. 

In different embodiments, fee decision to use a space for resdts m^ be DMndated by fee service, mandated 

30 by fee cUent, and/or requested by fee client A service may suggest fee use of a space for its results, e.g, m its 
advertisement In one embodiment, eifeer fee cUent or fee service may spawn a new space for results or use an 
existing space for results. See fee descr^on herein regarding spawning spaces. 

In one embodiment, fee use of a space for results does not necessarily mean that the service must put all 
. results in that space. There may be alternatives for any result a service generates. For ocample. part or an of fee 
35 result may be sent m^lihe in a message to fee client Alternatively, fee result may be put in fee space, and tiien a 
notification message may be sent to cUent, referencing fee result (e.g. inchiding a UW to fee result or to an 
advertisement for fee result). Anofeer option may be to put fee result in fee space, wife notification via an event 
fiom fee space. For example,, fee client and fee sendee may agree to can the result some particular name, a^^ 

fee cUent may register wife the space (usmg a space fecility such as described above) to receive an event when a 
40 result so named is added to fee space. See fee descrq>tion above on event notification. 
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Ttus. several different mechanisms may be employed withm 
service to return results to a cUent The actual results may be returned to the cUent by value in an XML mcssage.^.w 
results may be returned to the client by reference with the actual results (or advertisement for the actual results) put 
in a space and the client receiving a message referencmg the results in the space. Moreover, results, or resuhs 
5 advertisements, may be placed m a space and the cUent notified by event 

. AnothermechanisraforhandlingresuhsmaybeforthecUenttospecifyanotherserviceforthcre^^ 
fed to. For example, when a cUent runs a service that will produce results, the cUent inay instruct that service (e.g. 
through XML messaging) to send the resuhs to another service for fiiither processing. This may mvolve the client 
indicating the UW of an advertisement for the oth« service so that the result-prt)duci^^ 
10 to the other service m ord^ to run the other service and pass it the r<sults. In ttiis example, the result-prodncmg 
service may be a client of the other service. In some embodiments, the client, may send the schema or a pre- 
constnicted gate to the resulti)roducmg service t» access the service for fi^ 

for fiirther processing is a display service that may display 4e results for the origina] client This display service 
may be on or associated vrifli the same device as the client 
15 Result spaces and method gates may allow the distributed computing environment to provide a sm^le 

remote method invocation that is practical for thm cBents wife mimmal memory footprints and mmimal bandwidth, 
because it need not have the adverse side effects of huge prognffli objects (aldng with needed 
(necessarily) across the network to the client as m conventional remote method invocation techniques. Instead, 
results may be returned to a result space, and only if desired (and if they can reside on the client) are the actaal 
20, objects downloaded to the client 

The mechanism by which the distributed computing environment may provide for remote method 
invocation is as follows (refer also to the description of method gates in the Gates section heiem). An object may be 
advertised (e.g. as a service or as part of a service) in a space. The advertisement mctodes a reference that contams 
the IIRI (e.g. URL) of flie object, along wife other access parameters, such as security credentials and XML schema. 
25 A cUent may have or may construct a client mefeod gate for fee object, which for every mefeod of the object (or 
service) itself may have a wrapper method that takes fee mefeod parameters and creates a request XML message to 
invoke a mefeod of fee object Tlie XML message is sent to a service gate that mvokes fee a^ 
service object When feat mefeod returns a lesuft object, fee service gate may post fee result object m a results 
space, and may return a message to fee client wife a reference to fee result object, 
30 TiivB. for a Ghent to mvoke a remote mefeod. fee chent first sends a message to mstantiate an object 

service), such as described above. In one cmb«iiment, mstantiation of an object may mclude fee creation or 
spawning of a results space. In another embodhnent, results space creation may be independent from the object 
instantiation, histantiation may return the object URI to fee cUenVand fee cUent and service gates may be 
. dynamically created when a cUent requests mstantiation. hi some embodiments, a resuhs space may ab«idy exist 
35 and be advertised by fee object (service). Some part or all of the gates may also have been pre^constructed or 
. reused. 

Once a client has mitiated an object; a local call of fee appropriate client mefeod gate will affect a remote 
. call to fee actual remote object, as described above. The remote inefeod invocation approach of the distributed 
computing environment may be recursive, wife object references reimned to fee cUent. instead of fee objects itselt 
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when the client gate is called Note that such returned objects may already be instantiated. In some einbodiments, 
the client may make a decision to download an entire object itself rather than just remotely invoke it 

A method or service invoked as described above may generate a child gate that is associated with the 
results document The method may return a child gate (or the schema, URI and credentials for the client to construct 
a child gate) for the references instead of the references themselves. The client may then access the references 
Arough the child gate. The child gate may also be a method gate. 

As described above, this remote method mvocation provided by the distributed computing environment 
allows the real result object(s) to be stored in a service results space (vMch also may be created dynamically, by a 
servlet for example). The results space may be temporary. The results space may act as a queiy results cache. The 
results cache may be patrolled by server software (garbage collector) &at cleans-up old result areas. Distributed 
garbage collection may be en^loyed, as result spaces may fill up until tiiey are destroyed by a client indicating it no 
longer needs the space, or by an administrator on a server setting impropriate limits. 

Tuming now to Figure 23, an illustration of a default space 350 is provided. The distributed computing 
environment may provide at least one defeult space so clients can find an initial set of advertisements. A de^^ce may 
have a defeult space that exists locally, with a built-in pre-constructed gate. The services advertised m that default 
space may exist locally on that device, and they may provide system software that enables or feciiitates the device's 
participation in the distributed computmg envnx)nment 

The defeult space 350 may include one or more medianisms 352 to locate external spaces, as shown in 
Figure 23. One service in the default space may run the space discovery protocol described above to find external 
spaces. Also, external spaces may be advertised in the default space. Additionally, a service (e.g. a search engine or 
a proxy service to a search engine) may be advertised in the default space tot determmes or finds external spaces. 
Each space may be analogous to a file system mount point Thus, the distributed computing environment may 
provide searchable, dynamic mount points to services. A default space may be a client's initial mount poiDt to the 
distributed computing envirorunent 

A default space or access to a defeult space may be built in to a device. Through the defeult space and 
local services that may exist on the device, a client execution environment for the distributed computing 
environment may be provided A device's local services and defeult space service may have built-in pre-constructed 
gates. One of the built-in services Usted in tiie defeult space may be a service to nm Ae discovery protocol so that 
the client may locate additional (e.g. external) spaces. A defeult space may include a built-in service that proAddes 
an execution environment for clients that allows the client user to browse spaces, select, and then mstantiate 
services. Such a service may provide a shnple user interfece that allows a client to entire strings (e.g. keyword for 
space seardies), view or browse result references (e.g. space hstings, or service listings within a space), select items 
(e.g. to chose and instantiate a service), etc. 

Devices that primarily provide a service may also iiiclude a defeuh space and may inchide a built-in service 
m the defeult space that allows a service to manage advertising itself in various spaces. For example, a device, such 
as a printer, may have a built-in defeult service tiiat finds (perhaps through tiie discovery protocol) a space on a local 
area network and adds an advertisement for the printer sendee to that space. This service may also maintain the 
printer service advertisement withm the LAN space, for example, by renewing its lease or iQ>dating ttie printer's 
XML schema, etc. 
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For some devices that provide a. service, the overhead of finding a space to ad^ 
maintain that advertisement is undesirable. In one embodiment, rather than searching for and maintaining a qjace or . ; 
spaces to publish service advertisements, services on some devices may transmit their advertisements in response to 
comiectionrequests. For example, a printer device with a printer service that is avaUable on a proximity basis may 
5 notmaintainanadvertisementin.aspace(onthedeviceorextemaltothedevice). Instead, v*en another device 
establishes a connection with the printer device (for example, a user with a laptop nmning a cUent desires to print a 
document), the printer service may transmit the service advertisement to provide the XML service schema for 
connecting to and running the service that provides printing functionality on the printer device. Also, some devices 
may only maintain advertisements for their services in a certain vicinity or local network. Such a device may not 
1 0 desire to support or may not have access to transports for broader accessibiUty. 

Ctae example of a service device in vvMch h may be deshable for die device to avoid or limft 

service advertisements m a space is a device whose fimctionality is available on a proximity basis. Proximay-based 
serWcesmaypfovideadvertisementsoftheirfunctionaUtyuponrequest Theseadve^^^ 
accessible. For example, proximityWd services may be provided ma wireless communication 
15 "wireless" may refer to a conmimiications, monitoring, or control system in which electromagnetic or acoustic 
waves cany asignal through atmospheric spaceralherthanalongawiie. In most wheless systems, radio fiequency 
CRF) or infiaied (IR) waves are used. Typically, m proximity-based wireless systems, a device comprising a 
bansceiver must be within range (proxhnity) of another device to establish and maintain a communications channel 
A device may be a hub to cotmect other devices to a wireless U)cal AreaNetwork (LAN). 
20 As mentioned, embodhnents of the distributed computing environment may provide a mechanism using a 

lookup space that allows clients to rendezvous with services. In a proximity computing enviromnent. one 
embodiment of the distributed computing enviromnent may provide a service discoveo' mechanism that cUents may 
use to discover services without using lookup spaces as rendezvous points. An example of aproximity computmg 
enviromnent is an IrDA point-to-point communications emnromnent fa a proxhnity computing enviromnent. the 
25 proxmdty mechanism may find the "physicaT location of the service for the client. For example, m an IrDA 
enviromnent.thecUentdevicemaybephysicanypointedatthedeyiceincludmgtheservice^^^ 

to use. 

Ihe proxhnity service discovery mechanism may enable the client to directly look for service 
advertisements mdier than sendmg a lookup request to a lookup space to look for service^^^ Smcethe 

30 cUent device may have established a proxhnity comiection to the service device, the cUent may directly request the 
desired service. For example, a PDA cUent device may establish a proxhnily comiection to a prin^ 

client may "kno\^r to request a prhrter swvice connecfion on fte prmter device. 

'. fa one«nbodmient, ihe client may send a proximity service discovery message to the service device. The 
message may include infonnation that may specify a desired service on the servi^ 
35 has a proximity conn.?ction. In one embodhnent. a service on the service device may respond to ihe proximity 
service discoveor inessage, and may send to the cUent the service advertisement that the cUen^ 
ie desired service. The prpxhhity service discovery message may also hiclude mfoimation that may be rused to 
authenticate the cUent mid to establish the cKenfs capabilities on the service. Usmg the receded service 
advertisement, the cUent may establish a gate to establish communication with the desh^ 
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Nevertheless, it may still be desirable to publish advertisements for services that do not desire to or cannot 
maintain their advertkemerrts in a space &at is broadly accessible. In one embodiment of a distributed computing 
environment, a device that establishes a coimedion with a device that does not publish its service advertisement(s), 
suchasaproximity-baseddevice.maypublishserviceadyertisementsreceivedfrom^^ For 
example, a device that establishes a comiection ^th a proximity-based device and that has an alternate transport 
connection(s) may publish (or republish) service advertisements received from the proximily*ased device in the 
alternate transport enviromnent. thus aUowing the proximity-b^ 
(through the (re)published service advertisements) vvMch are outsi^^ 

me publishing device may locate a locally published service advertisement for the proximity-based device 

through a discovery and/or lookup service, or alternatively the semce advertisement may not be published by the 

local senrice device, but instead may be sent to the pubUshing device by the local de^^ 

com,ection. as descn^ed above: In one embo<toent,therepnblished service adverts 

as long as the device maintaining the advertisement is comiected to or able to connect to the local device. For 
example, if Ihe publishing device is disconnected from the local device (for example, moves out of proximity range 
of the device), the service advertisement may be made stale or removed. A lease mechanism may be provided to 
allow the space containmg the. advertisement to send lease renewal messages to the publishing device. The 
publishing device may verify its connection to fte local device, thus allowing the space to detect when the local 
device is no longer available. Rules for how the service advertisements are republished may be provided by the 
local device or by an administrative policy for the local vicinity (e.g. proximity area) or local network. 

Figure 24 iUustrates an example of a device bridging proximity-based devices onto ano&er ttansport 
mechanism to allow the services provided by the proximity-based devices to be accessed by devices outside the 
proximity range of the devices, according to one embodiment A publishing device 1404 may be comiected to a 
network 1412. such, as an Ethernet LAN or the Internet, etc, and may establish and maintain proximity comiections 
1414 with proximity devices 1400 and 1404. Proximity comiections may be wireless comiections or wired LAN 
comiections. for example. Pit>ximity devices 1400 and 1402 may each send a service advertisement to the 
publishing device 1404 upon comiection. or. alternatively, the publishing device may locate the service 
advertisements using a discovery and/or lookup service for the proximity connections, m^ 
may then make the services provided by the proximity devices available tp other devices 1408 and 1410 on the 
network 1412 by republishing the service advertisements 1416 and 1418 in space 1406. Space 1406 may be stored 
on the pubUshing device.or on ofter devices comiected to &eLAN (includmg devices 1408 and 14W^ 

Oflier devices on the LAN mcluding devices 1408 and 1410 may then discover space 1406 and look up the 
republished service advertisements 1416 and 1418 forthe proximity-based devices, establish gates to commmucate 
to those services (device 1404 may act as a proxy or bridge) on the proximily-based devices 1400 and 1402 using 
the XML message passing methods described previously., and send requests and recdve iesults to the proximity 
devices. Publishing device 1404 may act as a bridge between.the network 1412 and the proxhnity connections 1414 
to the proximity-based devices. . 

Leases ' 

Leases may be used in tiie distributed computing enviromnent to deal with partial Mure, resource 
synchronization (scheduling), and to provide an oideriy resource clean-up process. Uases may help the, ovendl 
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distributed system manage independent clients and services that may come and go. Hie various resources that 
clients obtain from services (including space services) may be leased from those services. In general, hot every, 
resource can or needs to be leased. In one embodiment, it is up to the implementation of each particular service to 
determine which of its resources need to be leased. In particular, resources used by a large amount of clients 
simultaneously may not need leasing or mstead may require custom leasing protocols. This class of leasmg may be 
left to the service provider. Custom protocols, such as those to implement transactions for example, may be built 
upon the base leasmg scheme. In one embodiment, the base leasing model is a relative time-based modd. . 

Services may issue leases to clients and provide operations on those leases. In one embodiment, all such 
lease fiinctionality of a service is part of that sendee's XML schema. Thus, a client may use its gate (corresponding 
to the service and constructed for the service's XML schema) to perform lease operations. In one embodnnent, all 
services tiiat issue leases provide the following lease operations (only allowed by the owner of the lease): (i) 
renewing a lease (parameters specified: lease'(c.g. lease ID, lease credential), new lease time requested), and Cu) 
canceling a lease (parameter specified: lease (e.g. lease ID, lease credential)). In one embodiment, all leases are 
granted for a particular amount of relative thne (duration of lease) that may be negotiated. Thie requestor may 
specify a certain amount of time (e.g. in seconds), and the grantor may grant the lease for any amount up to tiiat 
tune. In one embodiment, a -1 value naay be used to specify an indefinite lease. 

In one embodiment, a service advertisement may include one or more leasing addresses. In one 
embodnnent, the leasing addresses may be URIs. Standard leasii^ messages to renew and cancel service resource 
leases may be sent to a leasing UKI. An example lease URI: 
<leaser>service 1 ://resource 1 <Vleaser> 

An advertisement may also include various leasing messages as described above. Leasing inessages may 
mclude messages to reoiew and cancel leases for resources of the service. In one enibodiment, the messages may be 
comprised in an XML schema in the advertisement 

The leasiug mechanism may provide a mechanism to detect service and client frulure. Leases may also 
25 provide a mechanism to provide shared and exclusive resource access. In one embodiment, all service resources 
either have no lease (resource is not leased and therefore available), a shared lease (resource accessed by multiple 
clients), or an exclusive lease (resource is accessed by exactiy one client at a time). In one embodiment, all 
resources begin in the no lease state. A no lease state signifies there is no current access to the underlying resource, 
and indicates that there is an interest in fte resource iranamiQg in existence and thus available for leasmg. The 
30 leasing level may be increased fi-om none to shared, none to exclusive, or shared to exclusive, Lease isolation levels 
may also be decreased from exclusive to shared, exclusive to none, and shared to none. In one embodiment, clients 
may voluntarily increase or decrease the lease isolation level, or may be requested by the service to do so. A 
response message from the service may indicate if the isolation level change was accepted. 

Request-response message pairs may be employed to claim, release, and renew a lease. Each message may 
35 be tagged using a reserved XML tag to indicate that the message is a leasing message. The distributed computing 
environment doesn't necessarily define the complete composition of the message. In such an embodnnent, service 
developers may append custom message content, as long as, the niessage is tagged as a lea^ 

In one embodiment, clients that use leased resources may be expected to: (i) claim the resource as shared or 
exclusive, (u) release the resource claim (if requested or if finished witii resource), and (ui) respond to renewal 
40 messages (with anotiier claim at same or differwit isolation level). Renewal messages may be seat (e.g. in regular 
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intervals) by services to detect client feUure cases. The interval (at which the renewal message is sent) may be 
service specific. If a response to the renewal message isn*t issued after a specific amount of time (e.g. based on a 
time noted in the service advertisement), a resomre reclamation process may begin within the service, revoking the 
lease completely. In such an embodiment, renewal messages sent to clients should be handled in a timely fashion. 
5 Figure 25 illustrates the use of renewal messages both between a client and an instantiated service and between a 
service provider and a space service. Note that both cases may be considered as the use of renewal messages 
between a client and a service, since a service provider may be a client to a space's advertisement service. 

Renewal messages may arrive in an "out of band" fashion that may be inconvenient for the client to handle. 
That is, &e client cannot predict when a renewal message will be sent from Ihe service. Out of band message 
10 handling may com|)licate the client's logic and mcrease its complexity. To soke this problem, an aatqnmtic lease 
renewal medianism rosy be implemented to relieve the client of tibe responsibility of handling the out of band 
m^sages, and tfms reduce client complexity. In the automatic lease renewal mechanism, each gate (message, 
method, and/or event gate) may receive renewal messages and automatically respond to them without help firan the 
client The default response to a renewal request is to claim the lease at its current level Each message gate may 
15 contain a smgle, set-aside renewal response message that is automatically sent to the advertisement space service 
when the gate receives the renewal message. This"out of band" message is handled on behalf of the client, yielding 
a cleaner client pix>gramming model. In one embodiment, the gate may allow clients to register lease event handles 
to specify different isolation levels in the response message. 

The leasing mechanism may also provide a mechanism to detect stale advertisements. When a service 
20 publishes its advertisement in a space, that service obtains a lease on this publishing of its advertisement Each 
advertisement may contain a time by which die service promises to renew the advertisement to one embodiment, 
all time-out values are specified in seconds. If the service continues to renew its lease, the space is provided some 
assurance that the service advertised is still being offered The renewal time may be counted down towards zero by 
the space service. If the service does not renew its lease, the service may have failed, or it may no longer wish to, or 
25 be able to provide the service. When the lease is not renewed, the space service marks the service advertisement 
stale, so it does not make it available to clients. Services renew advertisements by sending a renewal message to the 
space. The space service receives these messages and resets the advertisement renewal time back to its initial value. 

In one embodiment, stale advertisements are not automatically deleted Depending upon Ae policies of tiie 
space, it may choose to delete stale service advertisements tiiat have e3q)ired for a reasonably 1^^ 
30 The deletion policy may be set by the space service. The space service may search for stale advertisements and 
either delete them or bring them to the attention of an administrator, for example. 

A space service noay use leases to manage the resources its feciUties provide to clients (including other 
services) of the space. For example, when a client desires to use a service, the space service may request a lease for 
the client as part of service instantiation. Service instantiation may be performed to allow a client to run a service. 
35 To instaiitiate a service, a client may first select one of the service advertisements published in a space. Ihe client 
may use the various fecilities provided by the space to look isp advertisements in tiie space. Then the client may 
request ttie space to instantiate the service. The lease acqufared during service instantiation is on use of the service 
advertisement (not the same as the lease on publishmg of die service advertisement). It should be noted that tiie 
' space service may allow multiple clients to have a lease on use of a service advertisement if the advertisement has an 
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indication it is shared Otherwise, the space' service only aUows one cUent at a time to have a lease on the service 

advertisement (exclusive).. 

Mother example of how a space service may uses leases to manage the resources its faciliti 

clients is when a client of the space registere to be notified when XML documents (e.g. service advertisements) are 
5 . added or removed from a space. The registering cUent of the space may obtain a lease on.this subscription to 
notifications- This lease enables the space service to know whether to continue sending notification^ Such a lease 
maynotbenecessarywhenacUenthasestablishedanactivesessicmwiththespace. Also, note that when a client of 
a space (could be a service) establishes a session with the space, the client may obtain a lease on the session. Ibis 
allows the space to manage any resources associated with the session. 
10 In another embodiment, aedism^uted computing environment misemploy a leasing med^ 

nottimeWL The lease may be generated whm an object is claimed for use. liBteado^ 
thedahnmeflrodmayacceptacanbackthatnotifiesthecurrentleaseholdertfaatsomeolherpartyw^ 
same object (e.g. service). Thus, as an alternative embodiment to timetased leases, instead dients msy make 
dahns on space objects (e.g. sendees). When another cUent desires a lease that is incompatible with the current 
15 leaseholder's lease, the service may send a "callback message" to the client Upon receiving fte callback message, 
the dieiit (i.e. client gate) may invoke i caflbadcmefcod to decide on a response to Ae callbadc message (?ceq) the 
lease.cancelthelease,changetheaccessleveltoshared,etc.). Once a response has been detemiined, the cHent gate 
sends a response message to the service. Tbis distributed mechanism for managmg leases may be implemented 

using the XML message-passing layer. 
20 For a non-tnne-based lease embodiment, fte distriTsutedcomputmg environment may provi^^^ 

for several levels (or kmds) of access tiiat allow a distiftuted algoriflm to detemune lease con^jatftility. Those 
levels may mclude: (i) keep the object in the space (keephiSpace), (ii) read the object in the space (readShared), and 
(iii) read exchisively flie object m the space (readExclusive). 

25 Attlfaentication and Securitv 

The distributed computing environment provides for spontaneous and heterogeneous distributed systems 
based upon an asynchronous message passmg model, where data and/or objects may be represented m a 
representation language sudi as XML. to the distnbuted computmg environment, cUents may comiect to sendees 
throughout the Internet, for example. The distnbutedcomputmg environment may enable large nmnbers of network 

30 devices to work together in.a reliable, dynamic, and secure fashion. The distributed computing environment may 
define a protocol ttiat substantially enables mteroperabiUty between compliant software con^nents (cUents and 
ser>dces). 

to the context of the distributed computing environment, a device may be a networidng transport 
addressable unit CUents and services may be hnplemented as Universal R^ource Identifier (URI) addressable 
35 instances ofsoftware or.fiimwarethatnm on devices. 

totemet space is mhabited by many points of content A URI is a mefliod used to identify any of those 
, pomts of cbntent, whether it be a page of text, a video or sound cUp, an image, software, firmware or other Internet 
cpntent Tbe most common form ofURI is the Web page address, whidj is a parfcdar fram or si^ 
a Uniform Resource Locator (URL). A URI typica^r describes the mechanism used to access fl»e resource, the 
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specific computer that the resource is housed in and the specific name of Ae resource (typicaUy a ffle name) on the 
computer. 

Clients and services (both may be implemented on devices as software and/or finnware) may be connected 
over tiie Internet, a corporate intranet, a dynamic proximity network, within a single computer, or by other network 
5 connection models. The siix and complexity of the devices supporting cUents and services may range, for example, 
fiom a simple light switch to a complex, highly available server. Example devices inchide, but are not Ihnited to: 
PDAs; cellular phones; notebook, laptop, and more powerfiil PCs; and more powerful computer systems, up to and 
including supercomputers. In some embodiments, the distance, latency, and implementation of cHents and services, 
may be abstracted, with a common discovery and communication me&odology, creating a "black box« effect. This 
10 definition approach allows software implementation issues to be dealt with by fee underlying platform, yielding a 
loosely coupled systOT that may be scaled to Internet proportions. 

The distributed computing environment may provide an Internet-centric programming model including 
WEB and XML. content representation, dynamic device discovery, and secure device communication tot is 
accessible from a wide range of network devices. The distributed computing environment may include a network- 
15 programming model abstracted above the CPU level. The programming model may include fee foUowing properties: 
» URI addresses 

» Strongly typed data called content (addressed wife URIs) 
. o Substantially unlimited amount of persistent content stor^e (e.g. stores), (containing XML and non-XML 
content, such as feat identified by MIME ^es) 
20 ° SubstantiaUy unlimited amount oftransient content memory caUed spaces (cont^ 

o Descriptive XML metadata (data about data) content advertisements feat may be stored in a space to riotify 
interested clients. 

» A substantially unlimited number ofinstructions (embodied as messages) 
<» Secure message endpoints (gates) addressed by URIs 
25 - Data flow support (event messages) to coordinate woric flow between distributed software 

Services and clients may run as programs withm fee distributed computing environment Services m^ 
advertise feeir capabilities to clients wishing to use fee service. CHents m^ or m^ not reside wifein the same 
network device, and feat device's code execution environment may or may not support fee Java platform. 

Using URIs to. address content and message endpoints gives the distributed computing environment a 
30 powerful addressing scheme. The address may specify fee location of fee content or endpoint, and may specify fee 
route (or transport protocol) to be used. Items addressed using URIs also may have an associated security 
credential. The security credential may be used to control vAist cHents are ^owed access to fee item, as well as 
wiudi operations aufeorized cUents are allowed to perform on that i^ 

The high degree of access provided by fee distributed computing envnonment may be controlled by 
35 . appropriate aufeentication and security systems and mefeods. Anfeentication and security in fee distributed 
con^>uting environment may include, but are not limited to: vaifying fee typing correctness of XML content in a 
message; securely identifying fee sender to fee receiver; a mechanism to check fee mtegrity of messages sent from a 
client to a service and vice versa; and a mechanism of describmg a service's set of accepted messages to a client and 
enforcing fee message requirements on messages received at fee service. The above listed security and 
40 aufeorization features may be leveraged in a smgle, atomic unit of code and data, TTie atomic unit of code and data 
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may be dynamically created. In one embodiment^ once created, the atomic unit of code and data may represent a 
message endpoint (gate), and may not be altered as to fee security and autborization policies unplemented dimng 
creation. 

A gate may represent the authority to use some or all of a service's capabilities. Each c^ability may be 
5 expressed in terms of a message that may be sent to a service. Gates may also be used for failure case detection 
when a client leases resources. 

Authentication and security may also include a mechanism for verifying that a client attempting to use a 
service is authorized to use the service; that the space from which the client receives the service advertisement from 
is authorized to provide the service advertisement; and/or that the service advertisement itself is authoii^ 
10 Message passing may be implemented in a messaging layer as the means of communicating requests from 

clients to services and of the services responding with results to the clients: The messaging layer of the distributed 
computing environment may substantially guarantee that valid XML messages are sent, and may provide 
mechanisms enabling a language-independent security modeL In the messaging layer, a sending message endpoint 
may be linked to a receiving message endpoint Hie two associated message endpoints may iwx)vide a secure, 
15 atomic, bi-directional message channel suitable for request-response message passmg between a client and a service. 

In embodiments of a distributed computing environment, an advertisement may be published in a space for 
aservice. Anadvertisementmay be an XML document that includes the XML schema and The 
SCTvice may also include a service ID token or credential in the advertisement, and may specify in the advertisement 
an authentication service to be used by both the client and the service. A client may then locate the service 
20 advertisement on the space, and use the advertisement to instantiate a message gate on the client The client may use 
the authentication service specified in the advertisement to obtain an authentication credential for sending in 
messages to the client. In one embodiment, the client may pass the service ID token or credential from the service 
advertisement to the autiientication service, and the authentication service may then use tiie service token or 
credential to generate the authentication credential for the client In one embodiment, the client may mclude a gate 
25 fectory that receives the necessary information to create the message gate, and the gate factory may construct the 
message gate and communicate with the authentication service to obtain the autiientication credential for the client 
A corresponding service message gate may be instantiated at the serviced 

The client, at some point, sends a first message to the service. In one embodiment, the client message gate 
may embed the client's authentication credential constructed by tiie authentication service in tiie message. When the 
30 service receives the message, it may use tiie same authentication service to verify the authentication credential 
received in the message. By sharing the same au&entication service, any of a variety of authentication protocols 
may be employed, with the details of geiierating the authentication credentials separated from tiie client and the 
service. Thus, a client may use different authentication credential protocols with different services. 

In one embodknent, the authentication service may determine flie capabilities of the cliesA (e.g. what the 
35 client is allowed to do on the service) upon first receiving tiie client autiientication credential from tiie service. The 
capabilities of the client may be bound to the client's identify. Then, the client's message gate may embed the 
authentication credential in evwy message sent from the client to the service. The messages may be received by the 
service message gate and then checked by the autiientication service to ensure that the message is fit)m the client and 
tiiat the message request is withm the capabilities of tiie client In anottier embodiment, tiie service message gate 
40 may handle capabilify determination and message diecking for capabilities without using the authentication service. 
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The client and service message gates naay work together to provide a secure and reliable message channeL 
The gates may serve as secure message endpoints that allow the client to nm die service by saiding and receiving 
secured, aufliorized XML messages to and from the service. 

Operations in the distributed computing environment may be embodied as XML messages sent between 
clients and services. The protocol used to connect clients with, services, and to address content in spaces and stores, 
may be defined by the messages that can be sent between the clients and services. The use of messages to define a 
protocol may enable many diiSerent kinds of devices to participate m the protocol Each device m^ be free to 
irnplement the protocol m a manner best suited to its abilities and role. 

A service's capabilities may be expressed in terms of the messages the service accepts. A service's message 
set may be defined using an XML schema. An XML message schema may define each message format using XML 
typed tags. The tag lisage rules may also be defined in the schema. The message schema may be a component of an 
XML advertisement along wilh the service's message endpomt (gate) used to receive messages. Extensions (more 
o^abilities) may be added to services by adding messages to the XML message schema. 

In the distributed computing environment, authorized clients may be able to use all of a service's 
capabilities, or may be limited to using a subset of the service's capabilitiies. In one embodnnent, once a set of 
capabilities has been given to a client, the client may not change that set without proper authorization. This model 
of capability definition may allow for services levels that run fix)m a base set of c^)abilities to an extended set 

Service instantiation may be performed to allow a client to run a service. To mstantiate a service, a client 
may first select one of the service advertisements published in a space. The client may use the various facilities 
provided by the space to look up advertisements in the space. Then the client may request the space to instantiate 
the service. Service instantiation may include, but is not limited to, die following steps: 

1. Client requests space service to instantiate a service. 

2. Space service verifies client is allowed to mstantiate the service. 

3. Space service obtains a lease on the service advertisement for ^e client with the lease request 
tune specified by the client. Alternatively, the service advertisement may be provided to the 
client \yithout using the leasing mechanism. 

4. Space service sends a message to the client fliat includes the lease allocated in steps 3, and the 
service advertisement of the service. 

5. Client runs the authentication service specified in the service advertisement, and obtains an 
authentication credentiaL 

6. Client constructs a client message gate for communicating vwth the service. 

hi order to provide trust between clients and services in the distributed conqiuting environment, a series of 
dynamically generated numbers (keys, or tokens) may be used as security or authentication credentials for clients. 
One or more credentials may be used to verify the right of a client to use a service and to verify niessages between 
the client and the service. Each client and service may have a unique aredential 

The type of authentication credendal needed to use a service may be returned to the client conducting a 
service search. In one embodiment, an authentication credential is an opaque object that must be presented each 
time a client uses a service. In one embodiment, fiie authentication credential laay be presented by a message gate 
oh behalf of a client in every message sent to a service. No matter what kind of authenticatkm credential is required 
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by a service, by using an authentication service external to the client and the service, the client and the service may 
not need to be awai« of the authentication credential stmcture or of the aiithenti 

An authentication credential may also include a transport-specific ticket in addition to the service ticket 
When running a service, depending upon the networking transport specified in the service advertisement, die 
5 transport may provide a secure connection. In some cases, if the data link layer is ah^y secure, it may not be 
necessary to use a secure transport over the aheady secure data link layo*. 

The concept of an authentication credential is abstract enough to allow various leveb of security based 
upon credential implementation. Levels of security may include, but are not limited to: 
L None (no message security -credential is empty or no credential) 
1 0 Messages with empty credentials or no credentials may be sufficient \^en security is enforced 

by the physical connectivity properties of the transport For instanc^^ 
coimected to just one h^t switch controUer is secure because the switches are wired 

secure manner. 

2. Signed messages (digital signatures) 

15 Signed messages may include a digital signature that enables the service (receiving the 

message) to verify die ori^ (client) of the message. 

3. Encrypted messages (transport may handle this) 

Encrypted messages add another level of security by scrambling the message contents so that 
another credential is required to unscramble it 
20 4. CapabOity messages (service functionality and user avvare) 

This level of security may provide for security capabilities on a user4?y-user basis (e.g. what 
the user is allowed to do), and may allow for fine-grained access control to services and 
individual service fimctions. 
Multiple levels of security zones m^ be used, due to the heavyweight implementation necessary to enforce 
25 the higher levels of security (capabilities & encryption). If the message transport supports (or helps support) ttiese 
security levels, the support may be leveraged to provide security level bridge services that bridge one level of 
security to another. 

As mentioned above, services without any security model may accept empty authentication credentials. For 
services that do not restrict access, a gate may be built without an authentication credential or with an "enqrty" 
30 authentication credential The gates for such services may not send an authentication credential witii each message, 
or may send an empty credential The autiientication sendee is one example of a service that may not restrict access. 
Other services may require a user and password pan:. 

Authenticating Service Access using Credentials 

35 In some embodiments, a mechanism for verifying that a cUent attempting to run a service is an autfiori 

client, for verifying that the service advertisement received by the client is an audiorized service advatisement, 
.and/or for verifying that tiie space from whidi die client received the service advertisement is authorized may be 
based upon a public key/private key asymmetric cryptographic mechanism. In tiiis medanism, an authorized 
sending entity may embed a public key in a message and encrypt the message includmg die public key with its 

40 private key. An entity receiving the encrypted message may decrypt the.message using Ihe public key and find the 
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same public key embedded in the decrypted message, and thus verify that the message is from the authoriwi entity^ 
since only that entity has the private key necessary to encrypt the message. Thus, an entity may issue a credential , 
that is substantially unforgeable, and that other entities may decrypt (with the appropriate pubUc key) to verify 
messages sent by the entity. 

5 Various key generation alg;orithms may be used in the distributed computing environment The 

composition of keys may be hidden from both cHents and services; thus, the client and service may not care what 
key generation algorithm is used. 

A Kerberos ticket is one example of a security credential that may be used in the distributed computing 
environment Keri>eros is a secure method for audienticating a request for a service in a computer network. 
10 Keiberos lets a user request an encrypted "ticket" from an auth^^ 

particular serdce. The user's password does not have to pass through the network 

Mechanisms ma/ be provided by the distributed computing «ivironment to substantially guarantee that 
messages sent between clients and services are not compromised. In one embodiment, a sender may embed a token 
containing information that may be used by the receiver to verify that the message has not been altered. Thm are 
15 several methods for generating the information to embed in the message. In one embodhnen^ .a hash of the message 
n^ be computed and sent with the message. Hashing may include the transformation of a string of characters into a 
usually shorter fixed-length value or key that represents the origmal string. Upon receiving the message, 
receiver may recompute the hash and check it against, the sent hash. If ttie message has been altered, it is Mgjdy 
unlikely that the same hash will be generated. The sender may encrypt the hash and send the corresponding public 
20 key in the encrypted message to substantialty ensure that the hash is not compromised. 

In other embodunents, an error detection scheme such as cyclic redundancy checking may be used. Cyclic 
redundancy checking is a method of checking for enrors in data that is transmitted 6 

embodiment using cyclic redundancy checking, the sender appUes an n-bit polynomial to the message and appends 
the resulting cyclic redundancy code (CRC) to the message. The receiver appUes the same polynomial (wdiich may 
25 alsobepassedinthemessage)tothemessageandcomparesitsresultwiththeresultap^^^^ Ifthey 
agree, the message has been received successfuUy. If not, the sender may be no 

Gate factories may also play a role m security, smce a gate j&ctory may be "trusted" code. Using a trusted 
gate factory to generate gates may help to ensure that gates are trusted code, and that the code is correct with respect 
to the service advertisement GUents may be required to present a cUent ID token or credential to the gate fectoiy as 
30 a means of authentication. Ser^aces may present a service ID tokwi or credential to cUents (e.g. through an 
advertisement) when a client wishes to create a gate. As discussed herem, a client and service token pair may be 
used to create a thfrd credential that may be used to aUow the client to send messages to the service. This third 
credential may be referred to as an authentication credential An authentication credential may be created by an 
authentication service during the authentication process. In one embodiment, tiie service may use any authentication 
35 poUcy at its disposal! In one embodunent, the authentication service administers the authentication poti^ 

of die service, and thus the service does not have to be aware of the particular authentication policy being used 

The client may construct its gate usmg an authentication credential that tiie client receives by running an 
autfientication service specified in die service advertisement This may allow the constnicted gate to send tiie 
' authentication credential witii each message to the service. When the service receives die first autiientication 
40 credential m a first message from the cUent, die service may use the authentication service specified in tiie service 

66 



wo 01/86394 * PCT/USOl/15134 

advertisement to authenticate the client, and thus may establish a binding of the authentication credential to the 
identity of the client 

As previously discussed, some results produced by a service may be advertised in ^ space and ultimately 
accessed using a results gate. The results gate may or may not contain the same security credential as the input gate 
5 used to generate the results. Because input to a service may be asynchronous from its output (ttie results), the results 
may have a different set of access rights associated with it For example, a payroll service may allow a different set 
of clients to initiate payroll than to read the payroll service's results (paychecks). Thus, a client may have to go 
through a separate authentication process to obtain access rights to the results, which may include receiving an 
authentication credential for die results from an authentication service specified m an advertisement for the results. 
10 Messagegatesmay offload most security checks fix)m services. Services may focus on providing capability 

and authenticating clients: A principle of least privilege may be supported by giving clients access to onfy those 
capabilities that are requested (or assigned). 

Security checks may occur when a gate is created and/or when a gate is used (whai messages are sent 
and/or received). When a client requests access to an advertised item (service), the process of gate creation may 
15 begin. During this process, the client gate factoiy may work with the service to mutually authenticate each other. 
The checks performed at gate creation time may be extensive, and may minimize the ninnber of checks performed 
during gate usage. After the service has aulheiiticated the chent, the service m^ detennine spedfic c^b^ 
the client (e.g. what the client is allowed to do on the service), and associate the capabilities wifli the client's 
audientication credential. Tliese specific capabilities may specify what operations the cUent is allowed to perform 
20 on the service. Since the gates may ensure that every message contains the audientication credential, the 
then check each request when it is received against the capabilities of the authenticated client 

Gate creation checks may ensure that a client has permission to use some or all of tiie service capabilities 
designated by the XML message schema. In one embodiment, tiiese checks may be unplemented using access 
control lists (ACLs) in conjunction with an authentication service such as Keiberos. A challenge-response sequence 
25 (such as a password) may also be used to authenticate a client In some embodiments, a hardware-based physical 
identification metiiod may be used to authenticate tiie cUent For example, tiie user may supply a physical 
identification such as a smart card for identification and auttiorization. Other mechanisms for authentication may be 

used in other embodiments. 

In one embodiment, whatever means is used to authenticate the client, the authentication may be invisible 

30 to both the cli^t and service, the gate fectory may be aware of vMch authentication service to use, and the 
authentication service handles the authentication mechanism and policies. Gate factories may be product and 
environment dependent, or may even be controlled by a configuration management system. In one embodimait, the 
degree and method of client isolation may be platform dependent, but is known to the gate fectoiy. In some 
embodiments, a hardware-based physical identification metiiod may be used to authenticate tiie client For example, 

35 tiie user may supply a physical identification such as a smart card for identification and authorization. CMher 
mechanisms for authentication may be used in other embodiments. 

Message gates in the distributed computing environment are typically associated with a single client The 
gate fectory may determme tiie means of association. The checks performed at message send time msy ensure tiiat 
the proper client is usmg the gate, hi one embodunent, gates may be passed in messages, and may be cloned if a new 

40 client wishes to use tiie gate. The cloning process may perform a new set of creation checks. 
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Once a client of a space (tiie client may be another service) finds the advertisement of a space service, the 
client of the space may run Ae space service, as it would any other service. Rimninjg a space service may involve 
usmg an authentication mechanism. Running a space service may include, but is not limited to: 

1. The client of the space may first run an authentication service Aat may be specified in the 
5 service advertisement ofthe space service to obtain an authentication credentiaL 

. 2. The client of the space may use the authentication credential, the XML schema ofthe space 
(fi-om space's service advertisement), and the URI of the space (fi*om space's service 
advertisement) to construct a gate for the space. In one embodhnent, the client may pass the 
information to a gate fectory to construct the gate. 
10 3. The client of the space may run the space service by using the gate to send messages to the 

service. 

4. When the space service receives tiie first message from the client, with the audientication 
credential embedded, the space service may use the same authentication service used by 1he 
client to obtain the authentication credential to authenticate the clieni thus establishing the 

15 client's identity. 

5. The space service may then determine the client's capabilities (e.g. what the client is 
aUowed to do on the space service) and bind the capabihties to the authenticatio 

As discussed in the Spaces section, a space's facilities may include an interfece for spawning an empty 
space with substantiaUy the same functionality (same XML schema) as the space from which it is spawned. The 
20 spawning fecility may be useful, among othar things, for dynamically generating spaces for results. When a 
requestor has spawned a space, only the requestor may be allowed to access the spawned space. For example, the 
spawned space may be for storing results fi^m a service that the client needs to keep secured. This security may be 
ensured by: 

• Creating an initial root authentication credential, and initializing the authentication service ofthe spawned 
25 space, so that the authentication service only authenticates the root authentication credential, and so that it 

returns no other authentication credentials (no other clients ofthe spawned space allowed initially). 
» Initializing the security policies of the spawned space so that the root identity associated with the root 

authentication credential has access to all facilities of tiie space, inchiding the security administration 

fecilities. 

30 . o Returning the root authentication credential and the service advertisement of the spawned space to the 

requestor of the spawned space. 

The requestor may buQd a gate to access the spawned space, since it is returned the authentication 
CTedential and the service advertisement pf the spawned space. In one embodiment, only the requestor and clients or 
services that the requestor passes the autiientication credential and the spawned space's service advertisenaent may 
35 access the spawned space. Such limiting of access to tiie spawned space may be useful when a cHent and service are 
using that spawned space to store results, for example, if the client and service destte to keep the results private. 

After running a service, die client may change the authentication policies of the spawned space using a 
security administration space fecility, and other clients or seryices may then access the spawned space. In addition, 
' the spawned space's service advertisement may be made available to other clients ofthe spawned space (the other 
40 clients may be services) using the discovery protocol or other means. 
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The. message transport layer in a distributed computing environment may include mechanisms for 
protecting the security and mtegrity of communications among clients and services during transport This security 
may be referred to as '^vire security" or "transport security" to distinguish it from the authentication security 
implemented by liie messaging system including gates. Encryption of messages may be provided at the message 
5 transport layer of the distributed computing envirorunent Services that request an encrypted transport may do so by 
tagging the XML advertisement The gate factory may then create a gate (or gates) that uses a secure message 
transport such as those provided by Bluetooth and HTTPS. 

HTTPS (Secure Hypertext Transfer Protocol) is a Web protocol that encrypts and decrypts iiser page 
requests as well as the pages that are returned by the Web server. HTTPS may use a multi-bit key size (may vary 
10 . from 40 to 128- bit or more) for a stream encryption algorithm (e.g. RC4X to provide an adequate degree of 
encryption for commercial exchange. HTTPS may be used as a transport in &e distribiited computmg environm 

Bluetooth is an emerging peer-to-peer wireless coimmmications standard. The Bluetooth key . generation 
algoridmis may be used iri the distributed computing envh-onment Bluetooth m^ support encryption keys. 
Encryption keys are transport dependent, while client, service, and combination keys may be transport independent 

• 15 

Fieure 26a - An authentication service provid ing an aut faenticatton credential to a client 

Figure 26a is a flow diagram illustrating an authentication service providing an authentication credential to 
a client accordmg to one embodiment A client in the distributed computing environment may desire a service to 
perform one or more functions on biehalf of the client In one embodiment, an authentication service may be 
20 provided for use by the client and the service when setting up a secure messaging channel. An authentication 
service may perform functions for the client and/or service including authenticating tiie client and/or sendee and 
negotiating the desired level of security and the set of messages that may be passed between the client and service. 
The authentication service may be a process that is executing witiiin the distributed computing eiivironment The 
authentication service may be executing on the same device as die service and/or the client, or alternatively the 
25 authentication service may be executing on a separate device such as an authentication server. In one embodiment, 
the authentication service may be an Internet-based service. The authentication service may have its own address, 
for example, a Universal Resource Identifier (URI), through which the client and/or service may cpramunicate witii 
the autiientication service. In one embodiment, the address of the authentication service may be provided to the 
client in the service advertisement for the service. The client and service sharing an authentication service may help 
30 insure that a secure messagmg chaimel may be established between Ihe client and the service, as any of several 
security and authentication protocols may be used in the messa^ng channeL 

In one embodiment, a client may present a client identification token or credential to an authentication 
service. Hie client token or credential may be sufficiently unforgeable to be used as proof of the client's identity. 
The authentication service may then check the client identification token or credential, and issue to the client an 
35 authentication credential that only the authentication service can create. Tbe authentication credential that is 
returned to the client is then sent m every message by the client to the service. In one embodiment, the client 
message gate is created by a gate fectory, which inchides the authentication creden^^ 

the message gate uacludes the authentication credential in every message that it sends to the service on behalf of the 
client When receiving a message, the service may then dieck the authentication credential. Smce only the 
40. authentication service can create the authentication credential, the service knows tiiat the client did not forge the 
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authentication credential. In one embodiment, the service may pass the authentication credential to the same 
auAentication service used by the client to ensure the authentication credential is valid, to verify that the client is an 
authorized client, and to find out the identity of the client 

All services, including space services and authentication services, may authenticate their clients. Once a 
5 service authenticates a client, the client may access the service. For example, in the case of a space service, a client 
may then obtain XML advertisements from the space. 

In one embodiment, a service may have a prearranged credential that all clients of ^e service are to use. In 
dxis embodiment, the authentication may provide the prearranged credential to a requesting client Any client 
presenting the prearranged credential to the service may be sgjproved by the service. 
10 In step 1000, the client may request an authentication credential from the authentication service. In one 

embodiment, the client may search for and locale a service advertisement for frie desired service. In one 
embodiment, the service advertisement may include an advertisement for the autiientication service to be used to 
obtain an authentication credential to be used in accessmg the service. "In one embodiment, the service 
advertisement may mclude an address such as a URI for the authentication service. In one embodiment, the client 
15 may send information to the authentication service requesting the authentication credential In one embodiment, the 
client may send information to a gate creation process, for example, a gate factory, and the gate creation process 
may access the authentication service to obtain the authentication credential. 

In step 1002, the authentication service may generate an authentication credential for the client Hie 
authentication credential may be a data element or data structure that may be ernbedded in messages in a messaging 
20 system and that may allow receivers of the messages to authenticate the sender of the message, to verify the message 
is from an autiiorized sender, and to verify feat fee message is a message fee sender is allowed to send to fee 
receiver. In one embodiment of a distributed computing environment, an aufeentication credential may be unique to 
fee messaging channel set up between a particular client and a particular service. Step 1002 is fiirfeer illustrated and 
described in Figure 26b. In step 1004 of Figine 26a, fee aufeentication service may return fee aufeentication 
25 credential to fee cheat In one embodiment, fee aufeentication credential may be returned directfy to fee client In 
one embodiment, fee aufeentication credential may be returned to a gate creation process, for example, a gate 
factory, which may feen use fee aufeentication credential in generating a gate. 
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Figure 26b - An authentication service gene rating an authentication credential 

Figure 26b is a flow diagram expanding on step 1002 of Figure 26a and illustrating an authentication . 
service generating an authentication credential according to one embodiment to step 1002a, in one embodiment, 
tiie authentication service may obtain a cUent token and a service token. In another embodiment, tiie authentication 
5 service may obtain only a client token. In one embodiment, the client token may be a unique identifier for the cliait 
in the distributed computing enviromnent In one embodiment, the service token may be a unique identifier for the 
service in tiie distributed computing enviromnent For example, tiie pubHc keys from a public/private key 
. encryption mechanism may be used as unique identifiers for flie client and tiie service. In one embodiment, the; 
client may receive tiie service token in tiie service advertisement, and tiie cUent may provide tiie client token and flie 
10 service token to flie autiientication service. In anotiier embodiment, tfie cUcnt may provide fiie client token and tiie 
service advertisement URI to tiie authentication service, and the auflientication service may retrieve tiie service 
token from the service advertisement 

In step 1002b. tiie authentication service may verify flie client and/or tiie saVice. In one embodhnent, flie 
auftientication service may use tiie cUent token and flie service token obtained in step 1002a to verify .flie cUent 
15 and/or service. In anoflier embodhnent, only a client token was obtained in step 1002a, and flius only ttie client 
token is used, to verify tiie cUent m step 1002b. In one embodiment the client may have previa 

client token vrifli tiie auflientication service, and tiie authentication service may compare tiie received cKent token to 
flie registered client token to verify tiie cUent as a valid client In one embodhnent, tiie cUent may access tiie 
autiientication service using a challenge/response mechanism such as a logon account widi password and tiius may 
20 be verified as a vaUdcUent one embodiment tiie service may have previousfy registered wifli tiie auflienticati^ 
service, and may have provided its service token to flie authentication service. Ihe auflientication service may flien 
verify tiurt tiie client is attempting to access a vaUd service by comparing flie received service token to tfie previously 
registered service token. Ottier types of cUent and service auflientication may also be used. For example, tiie client 
may provide a digital signature or digital certificate tiiat tiie authentication service may use to auflienticate tiie cUent 
25 and/or to auflienticate flie service the client is trying to access. 

In step 10p2c, flie autiientication service may generate an auflientication credential. In one embodiment 
&e auflientication credential may mclude an autiientication token fliat only flie autiieriti^^^ m 
one embodhnent, flie auflientication service may use tiie cUent token and flie service token m generating tiie 
autiientication credential. In anoflier embodiment tiie auflientication service may use. just tiie cUent token to 
30 generate tiie autiientication cred«itiaL In yet anoflier embodhnent flie auflientication service may not use an 
obtained token in tiie generation of tiie auflientication credential, but may instead use an auflientication credential 
generation algoriflim to generate a substantially unforgeable auflientication credential. In one embodhnent, flie 
autiientication service may combme flie service token and cUent token to create a unique aufl^ 
For example, flie service token and cUent token may be 64^it vataes. and flie two tokens may be combmed to 
35 generate a 128-bit auflientication crcdehtiaL Ottier embodhnents may use oflier mefliods to generate an 
auflientication credential. 
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Bridging Devices to the Distributed Net work Hnvironmeait 

Tliere may be. devices; external to the distn^uted compnting eiiv^ 
n«ssage passing model implemented by tiie distributed computing environment. TTiese devices may provide 
services that may be useful to clients in the distributed computing enviromnent. Tlie distributed compnftig 
environment may include a mechanism to bridge such exteinal devices to the distributed computing enviromnent so 
that clients in the distributed computing environment may access the services offered on such devices. Tlie 
distributed computing enviromnent may also leverage existing device discovery protocols for discovering such 
external devices for use in the distributed computing environment 

Many technologies define discovery protocols for publishing and monitoring a networks device 
composition. These technologies include, but are not limited to: Jini, SUP, Bluetooth, and UPnP. Furlhennonj. 
many I/O buses such as LonWorics. USB and 1394 also support dynamic discove*y pitrtocols. Tbc distributed 
computing envircmnent may leverage device discovery technologies by y^ing their implementations in an APL . 
Leveraging other device discovery protocols and providing a method to bridge to other discovery piotocok may 
allow the distributed computing enviromnent to discover devices or services on a wide variety of network and I/O 
buses. Device discovery in the distributed computing environment may thus be appUcable to a wide range of 
devices including smaD devices such as PDAs, even if they do not participate directly in the distributed computing 
envircnment Discovoy protocols may be defined at flie message leveL 

A bridging mechanism may be provided for '^vrapping'• one or more specific device discoveo^ 

such as Bluetoolh's. in a messaging API for the distributed computing environment Wrapping may inchide fiammg 
the device discovery protocol with code and/or data (the API) so that the protocol can be nm by cUents and/or 
services in the distributed computing enviromnent that would not otherwise be able to run it When run. the 
bridging mechanism may allow for a discovery agent that discovers devices by a specific device discovery protocol 
to publish services for those devices in a space in the distributed computing enviromnent The services present an 
XML message schema inteifece to clients in the distributed netwoA enviromnent, and are capable of operating the 
various devices discovered by the specific device discovery protocol, nms, service advertisements may be 
published for the services that operate the various devices discovered.by the underlying wrapped device discovery 
protocols. Ihe advertised services thus bridge devices (or services) external to fee distributed network enviromnent 
to clients on the distributed netwoik environment 

Figure 27 illustrates one embodunent of a distributed computing environment witii a space 1200. One or 
more discovery agents 1204 particii«te m an external discovery protocol , and bridge to the distributed 
computing enviromnent through bridging mechanism 1202. When the wrapped device discovery protocols are run. 
discovery agents 1204 through bridging mechanism 1202 may publish service advertisements 1206a-1206c in space 
1200. wherein each one of advertisements 1206a-1206c corresponds to a device or service discovered by one of 
discovery protocols 1204 outside the distributed computing enviromnent Clients may then access the external 
35 devices using the service advertisements 1206a-1206c in space 1200 to instantiate services on one of the agents 
1204 ttiat operates tiie corresponding external device or service. 

Thus. cUents of the distributed computing envfromnart may use discovray agents wrappmg device 
• discovery protocols to find devices. A sendee acting as a bridge to these devices may^te 

advertised, so cKents of the distributed computing environment may access flie services provided by the external 
4b devices. The advertised service is a service within tiie distributed computing enviromnent fliat is able to im«)ke a 
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device outside the distributed computing environment via another protocol or mvironment, thus bridging the ouUide 
device/service to the distributed computing environment. A cUent within tbe distributed computing environment 
"sees" only the advertised service within the distributed computmg environment and may not even be aware of the 
outside device/service. 

5 In one embodiment, the distributed computing environment may provide a version of a space discovery 

message protocol, such as the discovery FOtocol described in the Spaces section, that may be mapped to an 
underlying external device discovery protocol, including the wrapped device discovery protocols described above. 
The mapped discovery protocol may register itself .or be registered with a space, e.g. a defeult space, by placing an 
advertisement in that space. For each advertised discovery protocol, a subsequent results space to hold the results of 
10 the discovery protocol may be provided. 

Figure 28 illustrates an example of the ^ discovery protocol mapped to a Bluetooth discovery service 
1220 according to one embodiment Hie Bluetooth discovery service 1220 may first register 1230 widi flie 
distributed computing environment Ite Bhietooth discovery service 1220 may be wrapped in a bridging API, and 
an advertisement 1225 for the discovery service 1220 may be added 1232 in space 1224. A cUent or service may 
15 locate the discovery service advertisement 1225 on space 1224. When the discovery service IZIO is executed 
(utilizmg the API wrapper as a bridge between the discovery protocol 1220 and the distributed computing 
environment 1222), a new space 1226 may be created 1234 to store the results of the discoveiy process. Hie 
discovery service 1220 may store the results (again through the API wrapper) to discoveiy results space 1226 as one 
or more advertisements 1227. Alternatively, results of executing discoveiy service 1220 may be stored to space 
20 1224 or other preexisting spaces in the distributed computing enviromnent A snnilar method as illustrated in 
Figure 28 may be used to discover devices and ofiher services using other underlying discoveiy protocols. 

As mentioned above, there may be devices, external to fte distributed network environment, yMch do not 
support the message passing model implemented by the distributed netwodc environment These devices may have 
clients that may want to use services provided in the distributed computing enviromnent The distributed con^juting 
25 enviromnent may provide a mechanism to bridge the external clients or cUent devices to the distributed computing 
environment so that the clients on the external devices may access services in the distributed compirting 
enviromnent 

Agents may be provided that serve as. cUents in 4e distributed computing environment to bridge external 
clients to the distributed computing enviromnent, allowing the external clients to access services published in the 
30 distributed computmg environment In one embodhnent, an agent may have an XML^led back end capable of 
. commumcating with services m the distnTjuted computing environment using the message^ 

proprietary protocol (e.g. a protocol supported by the external device) on the fix>nt end to mterfece to the external 
device, and thus to the external cKent TTius, a client external to the distributed computing enviromnent may locate 
and access services in the distributed computing environment through the bridging agent, and may send requests to 
35 the services andreceive responses from the sendees, mchidingresdtsda^ For example, an external cUent may use 
flie bridgmg agent to run space discovery in fte distributed computing environmeirt, look vp advertised services, and 
invoke services in tiie distributed computing environment 

In one embodim?nt, the distributed computing environment niay provide a bridgmg mechanism for 
accessing Jini services from a distributed "computing en>nionment cUent Snxce Jini services m^ require Remote 
40 Method Invocation (RMI), and since clients in the distributed computing environment may commmiicate to services 
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using messages such as XML messages, a protocol bridging mechanism may be provided to enable the access of a 
Jini Service by.a distributed computing environment client In one embodiment, a connector mechanism may be 
deiSned that enables tihe dynamic advertisement of Jini services m distributed computing environment spaces, and 
tiiat also may enable the accessing of a Jini . service proxy from clients m the distributed computing environment In 

5 one embodiment, there may be Jini services that may not be bridged to the distributed computing environment 

In one embodiment, an agent may be provided as a service in the distributed computing environment that 
bridges the Jini RMI protocol used by Jini services to XML messaging used by distributed computing envnonment 
clients. When flie agent is started, the agent may perform a lookup on the Jini spaces for Tmi services that have a set 
of attributes. For every re^stered Jini service, the agent may generate.an XML advertisement that may correspond 

10 to the service and may re^ster the advertisement in a space m the distributed computing envhonment In one 
embodiment, an agent may register for event notification in the Jmi Lookup se^ 
a new Jini service is registered men mformed of a new Jini service, the agem 

to locate newly advertised Jini services and to update the distributed computing enviromnait space widi new XML 
advertisements for the new services. In one embodiment, when a Jini service is removed, the agent may receive an 
15 event notifying of tiie removal of the Jini service. The agent may then remove the XML advertisement for the 
service from the space. 

In one embodiment, to invoke a Jini service via an XML advertisement in a distributed computing 
environment space, a cHent may look up the service advertisement in the space and may send vaUd niessages to the 
agent to access the service. The agent may invoke the proxy service corresponding to tiie Jini service by invokii^ 
20 the coirespondmg method through an RMI caU to a service proxy. If the proxy is not mstantiated, the agent may 
dowiiload tiie proxy code and instantiate a new instance of die proxy object In one «iviromnent. every client 
connection may have a different proxy-instance. The incoming message from the client may be converted by die 
agent into a method caU for die proxy. The result from the method caU may be returned to the cHent as an outgoing 
message. 

25 In one embodimait, only simple Java types may be used as arguments to an RMI method. If complex Java 

types are required, then one or more data advertisements may be passed as arguments to the call, v^ere the data 
advertisements may indicate the location and access method of data for die complex Java types. In one 
embodiment, the agent may perform initial conversion from XML messages to an RMI method call mvocation 
dynamically. Since, tiie agent knows tiie service interface, it may generate tiie corresponding set of messages that are 
30 advertised to the client 

Figure 29 illustrates bridging a client 1250 external to tiie distributed computing environment to a space 
1254 in tiie distributed computiiig environment Bridgmg agent 1252 may serve as tiie go-between between client 
1250 and space 1254. Bridging agent 1252 may communicate witii client 1250 in a communications protocol 
understandable by tiie cUent 1250. Bridging agent 1252 may map tiie cUent's communications protocol into tiie 
35 XML messaging protocol necessary to communicate witii space 1254 periTorm tiie fecilities provided by space 1254. 
Bridging agent 1252, at client 1250's request, may locate and run semces on space 1254. For example, client 1250 
may request a list of aU services of a particular type from space 1254. Bridging agent 1252 may locate service 
advertisements 1256a-c and return the resuhs to cli^ 1250. Alternatively, tiie results may be posted in a results 
space, and the location of tiie results may be returned to tiie cHent 1250. CHent 1250 may tfien choose to execute 
40 service advertisement 1256a. and may send a message Cm tiie client 1250's communications protocol) to hridgmg 
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agent 1252. Bridging agent 1252 may then send the XML request message(s) necessaiy to execute the service 
represented by service advertisement 1256a, and.may return the results of the service to client 1250. Methods of 
handling the results of the service other than directly returning the results to the client 1250 may be used as 
described above in the section titled Spaces. Bridgmg agent 1252 thus may act as a service of the external client 
1250 (via the external client's protocol) and as a client within the distributed computmg environment to bridge a 
service within the distributed computing environment to the external client 

Sometimes, even within the distributed computing , environment, clients and services cannot dhectly 
communicate with each other, only to a common space. In this case, the space service will automatically create a 
service proxy that bridges client to service. The proxy's main job is to route messages between client and service 
through the space. The service proxy may be created dynamical^. The creation mechanism may be dependent 
upon space hnplementatian. Refer to Figure 30 for an illustr^on of a proxy mechanism. A client 554 and a service 
556 may not be able to communicate directly within the distributed compiiting enviromnOTt, eg., because Aey 
support different transport or networic protocols. However, they both m^ be able to communicate widi a space 552 
that supports both protocols. The space service may create a pro^ 550 to bridge the cUent 554 to the service 556. 
A common form of proxy is a browser proxy. A browser proxy (most commonly implemented as a servlet) may 
translate conventional Web page requests mto messages. Refer also to the description of space search services (and 
proxies therefore) in the Spaces section herem. 

The distributed computing environment may provide a mechanism for bridging clients in die distiibiited 
computing environment to enterprise services. In one embodiment of a distributed computing environment, a 
method for bridging clients to enterprise services may include a cHent within the distributed computing environment, 
a bridge service vrithin the distributed computing environment, and an enterprise service within the enterprise 
environment The distributed computing environment bridge service serves as a bridge service between the client 
and the enterprise service. An enterprise may be a corporation, smaU business, non-profit institution, government 
entity, or other kmd of organization. An enterprise may utilize an enterprise computing environment for conducting 
a portion of its business. The enterprise computing environment may include various enterprise services. Chants in 
the distributed computing environment may desire to use services in the enterprise computing environment An 
enterprise service may be based on a number of architectures, such as teee tiered cUent^server architectures. An 
example of an architecture that may be used to implement an enterprise service is Enterprise JavaBeans. Enterprise 
JavaBeans (EJB) is an architecture for setting up program components, written in the Java programmmg language, 
that run in die server parts of a enterprise environment usmg a client/server model In object-oriented programming 
and distributed object technology, a component is a reusable program building block that may be combmed wifli 
other components in the same or other computers m a distributed network to form an application EJB is built on the 
JavaBeans technology for distributing program conqwnents (Beans) to chents in a networic To deploy an EJB Bean 
or component, it must be part of a specific appHcation, whidi is cahed a container. In Enterprise JavaBeans, Acre 
are two types of beans: session beans and entity beans. An entity bean is described as one that, unlike a session bean, 
has persistence and can retain its original behavior or state. Using EJB, programs may be deployed across 
substantially all major operating systems. EJB»s program conqwnents are generally known as servlets (little server 
. programs). The ^pUcation or container that runs the servlets is sometimes called an application server. 
The bridge service interacts with the chent via XML message passmg to gather ^ 
to make requests to the enterprise service outside of the distributed network environment For ejcample, the bridge 
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service may be looked up and instantiated by the cHent just as any other service in the distributed computing 
environment The bridge service then may interact with the enterprise service to run the enterprise service. This 
interaction may use an interprocess communicatiohs architecture that the enterprise service can understand. As an 
example, if an enterprise service is implemented with Enterprise JavaBeans (EJB), a bridge service may 
5 coinmunicate with the enterprise service using EJB. The bridge service may then receive results ftom the enterprise 
service and may return the results directly to the client (in XML messages) or may place fee results in a qpace in the 
distributed networic environment (elg, a results space). To the cUent, the bridge service appesrs to be the only 
service (the enterprise service is hidden to the client), so the cUent does not have to support the architecture of the 
enterprise service. Multiple distributed networic environment cHents may use the same bridge service (each using a 
10 unique gate pair) to interact with the enterprise service. 

The bridge service or oAer agent may publish an advertisement for the bridge semce (and thus for the 
enterprise service) m a space m.the distributed computing envhonment For example, a bridge service or other 
bridge agent may use Java Reflection to examine Beans for services in an enterprise system implemented with EJB, 
and then weate service advertisemerits for bridge services to the Beans and publish those advertisemaits m spaces in 
15 the distributed computing environment. Reflection is a method for Java code to discover information about the 
fields, metiiods and constructors of classes, and to use reflected fields, methods, and constructors to operate on their 
imderlying counterparts on objects, within security restrictions. The Reflection API accommodates plications that 
need access to either the pubHc members of a target object or the members declared by a given class: Once the 
bridge services are advertised, clients may access the bridge services (and thus die corresponding enterprise 
20 services) sinularly to any other advertised services in the distributed network environ^^ 
architecture of the enterprise service providing the services. 

Client Displays 

There are several methods m v^ch results from a service run by a client may be displayed in a distributed 
25 computing environment Devices tiiat may display results may inchide, but are not limited to: CRTs on computers; 
LCDs on laptops, notebooks displays, etc; printers; speakers; and any other device capable of displaying results of 
the service in visual, audio, or odier perceptible format The methods for displaying results may inchide, but are not 
limited to: 

*» TheserWcemayretuniresults to a cUent directly or by reference, and the cUentniayha^ 
30 display of the results. 

. *» The service m^ return results to a client directly or by reference, and the client may pass the 
results to a display service directiy or by reference, and the displ^ service may display the r^lts. 
. « The seivice may directly handle the displaying of the results. 
» The service ihay pass the results to a display service directly or by reference, and &e display 
35 service may display the results. 

In the last method of displaymg results, tiie client may specify tiie displ^ service. For cxantple, there may 
be a display service on or associated with the device on which the cHent resides that the cUent wishes to use to . 
' display the results of the service. When flie cUenf runs the service, the chent may send a message to the se^ 
specifying the service advertisement of the cUent's display service. The service may then build a gate that allows it 
40 to send messages to the cHenf s displ^ service. Thus, when displaying results, tiie service invoked by the client 
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becomes a client of the client's display service and sends its results (directly or by reference) for display to that 
display service. More detail on the client-servic6 relationship, gates, and messagjng is included in other sections of 
this document 

Conventional application models are typically based on predetermined, largely static user mterfece and/or 
5 data characteristics. Changes to conventional appUcatibns mi^^ require code modification and recompilation. The 
mechanisms described for advertising services and for speciJfymg XML message schemas for communicating with 
services in Ac distributed computing environment may be used to provide a mechanism for applications (clients, 
services, etc) to describe dynamic display objects. Using the dynamic display objects, application behavior may be 
altered without having to download new code, recompile, or re-link tiie appUcation. Display schemas may be 
10 provided for displaying tiie same results m different formats, for « 
for displajdng the results on different display devices. 

Figure 31 illustrates one embodnnent of a client 1300 associated display 1302 and display service 
1304 according to one embodiment An advertisement 1306 for display service 1304 may be registered on space 
1308. An advertisement 1312 for service 1310 may be registered on space 1314 by service 1310. Alternative^, 
15 service advertisement 1312 and display sen^ice advertis^nent 1306 may be registered on the same space. CHent 
1300 may search for and discover (1320) service advertisement 1312 on space 1314, and may iien set iq) a gate to 
send requests to (and receive results or responses fiom) service 1310. In one embodiment, the messages may be in 
tiie form of XML messages specified in an XML schema received as part of advertisement 1312. CUent 1300 m^ 
send one or more messages (1322) to service 1310. The one or more messages may include messages for running 
20 service 1310 and for instructing service 1310 to send results to display service 1304 for display, and may specify the 
location of display service advertisement 1306. The advertisement location may be specified as a Uniform Resource 
Identifier (URI). 

The messages fi-om client 1300 to service 1310 may instruct service 1310 to praform one or more 
operations Aat produce displayable results. Service 1310 may retrieve display service advertisement 1306 fix)m 
25 space 1308 based upon the location information received from client 1300. The service advertisement may include 
the XML message schema and other information necessary to interfece witii (^play service 1304. Service 1310 
may then set up a gate to send requests to (and receive results from) display service 1304. to oflier embodiments, 
messages from cUent 1300 to service 13 10 may include tiie XML schema and other information needed for service 
1310 to construct a gate to display service 1304, or may include a pre-constructed 
30 During or after completing, operations requested by client 1300, service 13 10 may send the results of the 

operations to display service 1304 in the manner specified by die schema for display service 1304 (e.g: encapsulated 
in XML messages specified m die XML message schema or by reference as parameters for die display service), to 
' ' ms regard, service 1310 may be a cUent of display service 1304, Display service 1304 may then format and display 
the results received fiom or mdicated by service 13 10 on display 1302 for die client 
35 to some embodunents, service 13 10 may post the resulte of operations to a space such as a results space 

(not shown). Service 13 10 may then send a inessage to display service 1304 including a reference to tiie stored 
results of die operations, to one embodiment, the reference may be m die form of a URI. The d^pl^ service 1304 
may then retrieve the results from die space and display die results on display 1302. 

Conventional application models are typicaUy based on predetermined, largely static user mterfece and/or 
40 data characteristics. Changes to conventional ^tications may require code modification and recompilati^ Hie 
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mechanisms described for advertising services and for specifying XML message schemas for conrmunicating iwith 
services in the distributed computing environment may be used to provide a mechanism for applications (clients, 
services, etc) to describe dynamic display objects. Using the dynamic display objects, application behavior may be 
altered without having to download new code, recompile, or re-link the application. 
5 The dynamic display objects may be described in XML schemas. These schemas m^ be advertised in 

spaces. These schemas may be referred to as display schemas or presentation schemas. An application (or other 
services acting on behalf of the application) may then access the schemas fix>m the service advertisements to display 
data based upon formatting, data type, and other mformation stored in the schemas. 

The following is an example of a schema containmg dynamic display objects: 

10 

<elementnam^MeHvery" type=="Space:shipto" minOccu^ 
<type name^'TextField"> 
<element nam^" Address" typeF="string"/> 
<element nameF^"City" type="string"> 
15 <elementname="State"type="string"it> 



<typ€> 

20 

The above schema may be changed to the foliowmg widiout requiring an ^plication recompile: 

<element name="deiivery" type="Space:shipto" minpccurs=''0" > 
<type nameF="TextField"> 
25 . <element name="Name" type="string"A> 

<element name=" Address" type="string"A> 

<element name="City" type="string"/> 

<elementname="State" type?="string"/> 



</type> 

Figures 32A and 32B illustrate examples of using schemas of dynamic display objects accordmg to one 
35 embodiment In Figure 32A, application 1320 (may be a client, a service, or other qjplication) has been 
implemented with presentation schema advertisement 1324 stored in space 1326. A presentation schema 
advertisement may include elements describmg the data types, formatting specifications, fonts, locations, colors, and 
any other information usedi for displaying data for the plication on display 1322. There may be multiple 
presentation schema advertisements for application 1320. For example, there may be one schema for each display 
40 page in a series of display pages (for exainple, Web pages on a Web site). 
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In one embodiment. appUcation 1320 may invoke a discovery and/or lookup service to locate presentation 
schema advertisements. Hie discovery and/or lookup service may retum. an XML d^Kmment listing one or more . 
advertisements, and URIs to each of the schemas describing a particular display format, etc. Appliration 1320 m^ 
then select a presentation schema or schemas from the XML document AppUcation 1320 may then parse the 
5 schema, breaking out the elements of the schema into user interface components. Tire components then may be used 
to locate, format, and display results data on the appropriate display. Hie result data may be from nmning a service 
or from a results space, for example. Hms, as opposed to having, a static or predetermmed display, the appUcation 
. 1320 is configured to display results according to a presentation schema that may be dynamically changed without 

requiring a rebuild of the application. 
10 Presentation sdiemas may be provided for displaying the same results mdi^^ 

portions of the results for dlspfcy, and for displaying the result on diffin^ 

In one embodhnent. one or more presentation schema advertisements may be Stored in one or mor^ 

in a distributed computing enviromnent. As copies of an appUcation are invoked on one or more devices, each copy 
of the application may run a search for services to discover advertisements for the presentati^^ 
15 appUcations. -nius. a central, persistent store of the display information m^ be kept for multiple iristances of the 
applicadon or for other appUcations. The display mformation may be modified in the central location vrit^ 
requiring the recompilatiOTi and/or reinstallation of Ae appUcations. 

In Figure 32B, cUent 1328 may locate a service advertisement for service 1330 on a si»ce. When invoking 
service 1330. cUent 1328 may pass a location of presentation schema advertisement 1324 on space 1326 to service 
20 1330. When service 1330 is ready to provide results to cUent 1328. it may display the results on display 1322 
(which may be coupled to the device on which client 1328 is nmning) using the display mformation from the 
presentation schema provided by presentation schema advertisement 1324. To change the way the results are 
displayed, the XML messages in the presentatioii schema, advertisement 1324 may be modified, or a different 
presentation schema may be selected, without requiring changes at the cUent 1328 or service 1330. Service 1330 

25 may be a display service. 

A cUent, application or service may proWde a pluraUty of display schemas for displiQ^^ 

opemtions provided by one or more services. Alternatively, a display schema may include, m&rmation for 
displaying a variety of results for one or more cUents. Thus. cUent 1328 may use one display schema or a ptaia^ of 
display schemas. Two or more display schemas may be provided for formatting and dispkying the same r^^^^ 
30 different formate, or on di^nt displays. For example, one display schemafor a set of results may be provided for 
displaying results on a display screen, and another for printing the resuhs. Also, copies of the same appUcation. 
cUent.or service may run on devices with different display capabiUties, so two or more display schemas may be 
provided for supporting the display requiremaits pf the different devices. 

35 string Manaeement 

Strmg handling in conventiorial systems is generally not very eiBdent. especiaUy for va^ 

and may be waste&l of memory space. e.g. as the string is copied and/or mpve^ 

strii^handUngmaybeparticuMyproblematicinsmaUmemoiyfootprintsystemssuch^ 

■ amount of memory, particularly stack space and space for dynamic aUocation, may be Umited . in small footprint 
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systems. Thus, a more efficient method of hkidling strm^ 
such as embedded systems is desirable. 

Figure 33A illustrates a typical string representation in die C programming language. In C, a string may be 
represented by a character pointer 1450 (stringl) containing a memory location (address) of the first diaracler of a 
5 stringl452. Other character foUow the first character in the string 1452, and are typicaUy st^^^^ 

addressablebytelocationsinmemory. Characters hi C strings are typically 8*it THe characters in C strings nuy 
be any ASCn character. A C string must be termmated by a NULL character. NULL is platfonn defined as one of 
the 256 possible 8-bit values, but is typically the binary value ObOOOOOOOO. THe string 1452 occupies 13 bytes (12 
string characters plus the terminating character). 
10 An example of a string operation in C is the strlenQ fcnction. typically F^vided with standard C h-braiy 

Loaplementations. TtestrldiO Action takes a strii« pointer as mput and returns the le^ 
not inctading the tenninatmg character. For exan-ple. passing the character pointer 1450 to fte strlenQ fimction 
v^ould retnmAe length 12. TT,e strlenQ fimction may be implemented by •'walking the string until the te^^ 
character Is located, counting each character. 
15 Strin? copying in C is typically handled by a strcpyQ or a stmcpyQ C Ubraiy fimctions, which are 

implemented as: 

char *strcpyCchar *dest, const char *src); 
char *stmcpy(char *dest, const char *src, size_t n); . 
The sticpyO taction copies the string pointed to by the character pon^^ 
20 the string pointed to hy character pointer dest . The strings may not overlap, and fee destination string dest must be 
large enough to receive the copy. 

•ae stmcpyO fenction is similar, except that not more than n bytes of src are copied. Hius. if there is no 
terminatingd^ct«amongthefiratnbytesofsrc.theresultwiUnotbetermi^^^^ If desired, an mstruction may 
be placed in the code following a strncpyO to add a termmation character to the end ofthe dest string. Inthecase 
25 where the lengtti of src is less than that of n. the mnainder of dest will be padded with nulls. lUe strcpyO and 
StmcpyO fimctions return a pointer to die destination string dest . 

Figure 33B illustrates an example, of die results of fte stmcpy() fimction on string 1^^^^ 

called with the following parameters: 

30 stmcpy(strhig2, stringl+3, 5); 

where stringZ is character pointer 1454 pointmg to the. first byte after the terminating character of string 1452, 
stringl+3 is character pointer 1450 mcremented by 3 bytes, and 5 is the number 

. fromthesourcelocationstringl+3 to stringZ. Aflercopyh^ 
35 stringlmaybesettothetemnnatingcharacter(thccharact«mayhavebeeni^^ 

priortothecopy). •nius.thetwostringsnowoccupy(13 + 6)=19bytesofmemory. If die strcpyQ fimction was 

. appUed with character pointer 1450 as die source string, the OTigmal^ ^ 

• . occupy.(13»2) = 26bytes. • 

Figure 33C iUustrates an effident method for representmg and managing strings m general, and in ^ 

40 systems such as embedded systems in particular. String 1452 is stored in memory as 12 bytes (no terminating 
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character is required). String structure 1460 includes pointers (Address(A) and Address(L)) to the first and last 
characters of string 1452. Using this string structure, the string's length may be effici^^^^ 
the pointer to the first character from the pointer to the last character. 

Operations such as string copy operations strcpyQ and stmcpyO may also be handled more efficiently. 
5 With string structures such as those illustrated m Figure 33C. a new string structure 1462 may be created, and the 
first and last diaracter pointers may be initialized to point to tiie respective characters in string 1452. Tbus, a 
portion or aU the string 1452 does not have to be copied to new storage for the As strings can be hundreds or 
. even thousands of characters long, the memory saved using the string sfr^ 
take advantage ofthem may be considerable. This method of handling copies of portions or aU of a string may be 
10 caUed"substringmanagement,Vasitdealswiththeefl5denthan^ 

Other string fractions fiom the standard C string UT>ra^ 
advantage of the string structure as illustrated m Figure 33C. Examples of other C string functions inchide, but are 
not limited to: strstrO> strcatQ. aid sprintfiQ. Tlie string handling structures and methods as described in Figure 33C 
may be used, along with the hierarchical structure of XML documents, to provide more efBcient handling of XML 
15 text (such as XML messages) in systems with small memory footprints such as embedded systons. Hie foUowing is 
a simple example of an XML schema defining a purchase order 

<1I)0CTYPE piirchase.order SYSTEM "po.dtd"> 

<purchase.order> 
<date>22 May 2000</date> 
20 <billiDg.address> 

<name>John Sniith5/name> 
<street;>l23 Main<street?> 
<city>AnywiieTe<^city> 
<state>MA<;/state> 
25 <2ip>12345-6789</zip> 
<ybilling.address> 
<items> 
<itein> 
<quantity>3</quantrty> 
30 <productJiumber>248</productnumber> . 

<description>Decoratiye Widget, Red, Large</description;> 

<umtcost>19.95<yunitcost> 
</itera> 
<item> 

35 <quantity>l</quantity> 

<productnumber>1632<productnumber> 
<descriptioi£>Battery, AA, 4-pack</desaiptioi]> 
<unrtcost?^4.95<toitcost?> 
<Jitm£> 

40 <ritem^ 

. ^purchase.order> 

The hierarchical structure of XNCL documents may allow them to be processed in a recursive feshion witii 
successively smaUer portions of the document processed at each level of recursion. References to various portions 
45 . are recorded and processed recursively: String structures as described m regard to Figure 33C may be used to 
record tiie various portions. In tiiis manner, the content of specific XML tags (one line m the above acample), in 
<ine embodiment the smallest unit of the XML document processed recursively, may be determined efficiently. 
Documents with repeated tags in the same scope may also be handled efBcientfy^ 

be enumerated and processed efficient^. 
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A lecureive method for processing an XML document using string structures similar to those described in 
Figure 33C may accept a string structure representing the entire XML document string and pointmg to the first byte 
and the last byte in the document string. The method may then locate the next subsection of the document and pass 
a string structure representing the substring of the entire document string containing the subsection to a processing 

5 function for the subsection type. The subsection itself may be broken into another level of subsections represented 
by string structures passed to processing fimctions for die subsection type. The me&od may continue in the 
recursive processing of the XML document subsections until the enfe 

Using the string structures with the recursive processing allows tiie processing to be done without creating 
copies bfthe subsections for processing. Copying of subsections may be particularly costly in recursive processing, 

10 because as the recursion goes deeper, more and more copies ofthe same data are made. Using die string structures, 
only fee string structure containing the pointers to the first and to 

passed down to the next leveL O&er operations, such as determining the lengtii of a subsection, may be performed 
efiBcientiy using , the address information stored in tiie string structures. Also, by using the string structures, 
terminating characters such as those used to terminate C sttings are not necessary, conserving memory in small 
15 footprint devices such as embedded devices. 

XML representation of Objects 

As preyiously mentioned, Jini RMI may not be practical for some clients, such as thm clients with minimal 

memory footprints and mminial bandwidth. The serialization associated with the Jini RMI is slow, big, requires the 
20 JVM reflection API, and is a Java specific object representation. Java deserialization is also slow, big and requires 

a serialized-object parser. Even Java based thm clients may not be able to accept huge Java objects (along wiOi 

needed classes) being returned (necessarily) across the network to the client, as required in Jini. 

A more scalable distributed computing mechanism may be provided by embodiments of a distributed 

computing environment A distributed computing enviroranent may mclude an API layer for fecilitating distributed 
25 computing. The API layer provides send message and receive message capabilities between elicits and services. 

This messaging API may provide an interface for simple messages in a representation date 

as in the extensible Mark-up Language (XML). Note that vdiile embodiments are described herein errq)laying 
XML, other meta-data type languages or formats may be used in alternate embodhnents. In some embodhnents, the 
API layer may also provide an interface for messages to communicate betweei objects or to pass objects, such as 

30 Java objects. Objects accessible through API layer 102 are represented by a representation data format, such as 
XML. Thus, an XML representation of an object may be uMuipulated, as opposed to 

The API layer may sit on top of a messa^g layer. The messagmg l^er may be based on atepresentation 
data format, such as XML. In one embodiment, XML messages are generated by the messaging layer according to 
calls to the API layer. The naessaging 1^^ may provide defined static messages tiiat may be sent betvireen clients 

35 and services. Messaging layer m^ also provide for dynamically generated messages. In one embodiment, an 
object, such as a Java object, may be dynamically converted (compned) mto an XML representation. The object 
may include code and/or date portions. The object's code and/or date portioiis may be compiled into code an^ 
segments identified by XML tags in the XML representation. .The messaging l^er may then send die XML object 
representation as a message. Ck>nversely,te messaging layer may receive an XML representation of an The 

40 object may dien be reconstituted (decompiled) from that message. The reconstitution may examme the XML 
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representation for tags identifying code and/or data segments of the XML representation, and use infonnation stored 
in the tags to identify and decompile tiie code and/or data portions of the object 
Creating and sending an XML representation of an Object 

Figure 34 illustrates a process of moving Java objects between a client 1500 and a service 1502 according 

5 to one embodment Service 1502 may be any service supported in the distributed computing environment, 
including space services. Client 1500 employs a gate 1504, which may have been created using an XML schema 
received from a service advertisement for service 1502, to communicate with a corresponding gate 1506 for service 
1502. At some point, client 1500 may need to send Java object 1510 to service 1502. Java object 1510 may 
reference otfier objects, which may in turn reference other objects, and so on. Java object 1510 and its referenced 

10 objects, tiie objects th^ in turn reference, and so on, m^ be referred to as an objert 

Java object 1510 may be passed to a Java object compiktion process 1512 to be compiled to pro^ 
XML representation ofthe object graph. TheXMLiepresentationof the object gr^hm^ be passed as an XML 
data stream 1514 to gate 1504. Hie XML data stream 1514 may include an XML representation of all the objects m 
fte object graph. In one embodiment, the objects in the object graph may be stored recursively in the XML data 

15 stream 1514. 

Gale 1504 may then package the XML data stream 1514 in a message 1516 and send flie message 1516 to 
gate 1506 of service 1502. Gate 1506 may extract the XML data stream 1514 from XML message 1516 and send 
the XML data stream 1514 to an XML data stream decompflation process 1518 to be decompiled to produce the 
object(s) comprising the object graph, mcluding Java object 1510. In one embodunent, the objects in the object 
20 graph may be stored recursivety in the XML data stream 1514, and thus a recursive decompilation process m^ be 
used. 

When service 1502 needs to send a Java object to cHent 1500, a substantially similar process may be used. 
Java object 1520 may be passed to a Java object compilation process 1512 to be compaed to produce an XML 
representation ofthe object graph. The XML representation ofthe object graph may be passed as an XML data 
25 stream 1522 to gate 1506. Gate 1506 may then package the XML data stream 1522 in a message 1524 and send the 
message 1524 to gate 1504 of client 1500. Gate 1504 may extract the XML data stream 1522 from XML message 
1524 and send the XML data stream 1522 to an XML data sUream decompilation process 1518 to be decompiled to 
produce the object(s) comprising the object gr^h, including Java object 1520, 

In another embodunent, the gates may be responsible for the compUation and dwx)nq)ilation of Java 
30 objects. In this embodiment, Java object 1510 may be passed to gate 1504. Gate 1504 may then pass object 1510 
to a Java object compilation process 15 12 to be compiled to produce an XML representation ofthe object graph in 
an XML data stream 1514. Gate 1504 may then package the XML data stream 1514 in a message 1516 and send 
the message 1516 to gate 1506 of service 1502. Gate 1506 may extract die XML data stream 1514 from XML 
message 1516 and send the XML data stream 1514 to an XML data stream decompilation process 1518 to be 
35 decompiled to produce the object(s) comprising the object graph, mcluding Java object 1510. The process of 
sendmg a Java object from service 1502 to client 1500 inay be substantially similar to the process of sending an 
object fix)m fte client to the service. 

In one embodiment, object compilation process 1512 and object decompilation process 1518 may .both 
exist oil the client 1500 and the service 1502, and may be progranamed to perform compilation and decompilation 
40 substantially similarly on the two devices, thus ensuring the object(s) ou^ut on one end are substantially identical to 
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tiie object(s) input on the other end. In one embodiment, XML schemas including d^ptipns of Java objects may 
be used on both the client and/or the service in the compilation and decompttation processes, ti one embodiment, 
XML schema(s) to be used in the compUation and decompilation of Java objects may be passed by the service to the 
client in the service advertisement 
> XML provides a language- arid platform-independent object representation fonnaL Thus, the process as 

illustrated in Figure 34 where an object is compiled into an XML representation of the object and decompiled to 
reproduce the object may not be limited to moving Java objects, but in some embodhnents may be appUed to 
movmg objects of other types between entities m a network. 

0 JVM compilation/decompilation API 

Figures 35a and 35b are data flow diagrams iUustratmg embodhnents ^ere a virh^ 

mcludcs extensions for compiling objects (e.g. Java Objects) mto XML representations of the objects, and for 
decompiling XML representations of (Java) objects into (Java) objects. The JVM may supply an Applications 
Programming hiterfece (API) to Ae compilation/decompilation extensions. The client 1500 and service 1502 may 
15 be executing within JVMs. The JVMs may be on the same device or on different devices. 

In both Figure 35a and Figure 35b, the JVM XML compiler/decompilo* API 1530 may accept a Java 
object 1510 as input, and output mi XML representation of the object 1510 and afl its referenced objects (Ae object 
graph of object 1510) m an XML data stream 1514. In addition, the JVM XML compiler/decompQer API 1530 
may accept an XML data stream 1522, which includes an XML representation of object 1520 and afl its referenced 
20 objects (the object graph of object 1520), and output Java object 1520 (and dl the objects 

Figure 35a illustrates one embodiment where, when sendmg Java object 1510, the cUent calls the JVM 
XML compiler/decompiler API 1530. The cHent 1510 passes Java object 1510 to the API 1530, which compiles the 
object to produce its XML representation, stores the XML representation in XML data stream 1514, and ou^uts 
XML data stream 1514. The client may then pass XML data stream 1514 to gate 1504. Gate 1504 may then 
25 package the XML data stream 1514 m an XML message 1516 and send message 1516 to service 1502. 

Upon receiving XMl. message 1524 from service 1502, gate 1522 may extract XML data stream 1522 
from message 1524 and pass data stream 1522 to client 1500. Client 1500 may then call the JVM XML 
compiler/decompHer API 1530, passing API 1530 the XML data stream 1522. The API 1530 may then decompile 
the XML data stream 1522 to produce Java object 1520 and odier objects m its object graph, returning the objects to 
30 client 1500. 

Figure 35b illustrates another embodiment where, ^^en sendmg Java object 1510, the JVM XML 
con^iler/decompiler API 1530 is called by the gate. The client 1510 passes Java object 1510 to gate 1504. Gate 
1504 then passes object 1510 to API 1530. wMch conq)iles die object to produce its XML re^^ 
XML representation in XML data stream 1514. and outputs Xl^d^ Gate 1504 may then padcage 

35 theXMLdatastreaml514inanXMLmessagel516andsendmessagel5l6toservice^l^^^ 

Upon receivmg XML message 1524 from service 1502, gate 1522 m^ extract XML data stream 1522 
from message 1524 and pass data stream 1522 to the JVM XML compiler/decompiler API 1530. The API 1530 
m^ then decompUe the XML data stream 1522 to produce Java object 1520 and other objects m its object gr^h. 
The gate may then send Java object 1 520 and the other objects to client 1500. 



84 



10 



15 



PCTAISOl/15134 

WO 01/86394 

In one embodiment, the JVM XML compiler and decompfler may be implemented as integrated fimctions 
of the JVM. in another embodiment, the XML compUer and decompfler may be endjodied in API method 
invocations in standard extensions to the JVM; thus, the core JVM does not have to be modified. Ihe JVM may 
supply the JVM XML compaer/decompaer API 1530 to pn)cesses (cUents and/or services) executing within the 
JVM to allow the processes to access the Java object compilation/decompilation fimctionality provided by the JVM. 
In one embodiment, for a process to utilize the object compilation/decompiMon. the ^ 
is executing must have the JW XML compiler/decompiler fimctionality and API 153a 

Methods using reflection and serialization to tnmsfoim and send objects are typically implemented in 
applications separate from the JVM. Ite application must repeatedly access the JVM to pick apart an object one 
field at a time as the transitive closure of the object is dynamically analyzed. Hus tends to be a.slow and 
cumbeisome process, whfle also requiring large amounts of appKcalion tad ^ 

Implementing the Java object compilation/decompUation fimctionaUty viflun ihe JVM is advantageous 
because the JVM already understands the concept of, and contents o^ an object graph. TTius, the 
compitotion/decompflation fimctions may leverage the knowledge (and reuse code)ofthe JVM in p^^^^ 

graph to produce the XML representation, and in parsing the XML representation to produce the object graph. 
Thus, the compilation/decompilation fimctioi^ may not have to dq,licate fimctionaKty that is 
as do object sending methods using reflection and serialization. This may allow the code footprint of Ihe 
compaation/decompilation fimctions to be smaUer than that of object sending methods using reflection and 
serialization. Also, an object may be complied or decompDed- by a single call to the JVM XML 

20 compiler/decompiler API. 

In addition, integrating the compilation/decompilation of objects with the JVM may aUow the compflation 
and decompilation of objects to be perfomied filter than methods using reflection and serial 
object traveml model implemented with reflection and serialization, the code outside the JVM does not know the 
structure or graph of the Java object, and thus must traverse the object graph, pulling it apart, and ultimately must 
repeatedly call upon the JVM to do the compilation (and the reverse process for decompilation). This process may 
be slowed by the necessity of making repeated calls to the JVM, outside the code. Having the compilation and 
decompilation fimctionality integrated withthe JVM. as described herem, avoids having to make repeated calls fi«m 
code outside the JVM to the JVM. hi one embodiment, an object may be complied or decompiled by a smgle call to 
the JVM XML conqjiler/decompiler APL 

In one embodiment, the compilation/decompilation fimctionality may be fanplemented as a service in the 
distributed computing enviromnent The service may publish a service advertisement in a space. Aprocessmthe 
distributed computing enviromnent may use a search or discovery service to locate the compilation/decompilation 
service. The Focess (a client of the service) may then use the service by passing Java objects to be compiled into 
XML representations and/or XML representations to be decompfled into Java objects to tiie service. 

Java objects may include code (the object's methods) and data. An object's code may be non-transient; the 
code does not change once the object is created. An object's data. However, may be transient. Two objects aeated 
from the same Java dass may mclude identical code, but the data in the two objects may be different to one 
embodiment. &e compilation fimction may compile a Java object's data mto an XML representation of the object, 
butmaynotmcludetheobject'sactualcodeintheXMLiepresentatibn. M one onbodiment, infomiation about the 
40 object may be included m the conq.iled XML representation to indicate to the receiver how to recreate flie code for 
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the object nie XML representation may then be stored in an XML data stitam and sent (e.g. in.a message) to a 
receiving process (cUent or service). Tte receiving process may then pass the XML data stream to the 
decompilation fimction. The decompilation fonction may. then decompile the XML data stream to produce the Java 
object including its data. In.one embodiment, the code for the object may be reproduced by the decompilation 
5 ftocdoii using Mormation about the object inchided in the XML representati^^ 

. . statically defined and the JVM.receiving the object may be able to reproduce the code (if necessary) using its 
knowledge of the object 

In one embodhnent. the XML representation of an object produced by the compilation fimction may 
inchidetheJavaobject'sdataandinfoimationabouttheJavaobject The information may include class infonnation 
10 for the Java object M object signature may be included .in the m&iination and may be used to identify the 

class, etc. The deconq,il^tion fimction may recreate the code for the Java object using the mformation about the 
Java'object and may decompile the data fiom ti>e XML data stream into the Java object Thus, a complete object 
including its code and data may be reproduced on the JVM executing the receiving cUent or service firom the 
decompiled data and the information describmg the object In one embodiment, the infonnation describmg the 
15 object may be stored in one or more XML tags, fa one embodiment, the cUent or service nxeiving the XML date 
stream may include an XML schema that describes the object, and the XML schema may be used to i«constniet the 
Java object from the decompUed data and fit,m tiie infomiation about flie Java object The decompilation process 
niay proceed recmdvely through the object graph, reconstructing the objects referenced by the object by 
decompiling the referenced objects' data from the XML data stream and recreating the referenced objects' code 
20 fiom infonnation about tiie referenced objects in the XML data stream. 

to one embodhnent, the XML representation of flie object produced by tiie compilation function may 
include the object's data and mfonnation that identifies the code of an object In one embodiment, the mfoimation 
identifyingthecodeoftheobjectmaybestoredinoneormoreXMLtagsintheXMLdatastream. When received, 
the decompilation fimction may recreate the code for fl>e Java object using the infonnation about the code from the . 
25 XML data stream and decompile the data for flie object from flie XML data stream. Ihus. a complete object 
includmg its code and data may be reproduced on the JVM executing the receiving cUent or service from the 
decompiled data and tiie mfonnation describing tfie code of the object 

Several scem«os of using XML representations of objects to transfer objects between entities (typically 
cUents and services) in a distributed computing environment mcluded for clarification, Ihese scenarios are 

30 exemplary and are not intended to be limiting. 

In a first scenario, a service may use the XML compUer/decompiler to compile a Java objert into a^ 

. representation of the object and send the XML representation to a cUent The cUent may the use the XML 

compner/decompfler to decompile the XML representation and perform operations on the .data within the object, 

and later may use tiie XML compiler/decompiler to compile tiie object into an XML representation of 4e object and 

35 return tiie XML representation of&e object to tiie service. . . , 

In a second scenario, a service msor use the XML compiler/decompiler to compfle a Java object mto^ m 

XMLrepresentationofflieobjectandsendtheXMLrepresentationtoacUent The cUent may flien send the XML 
• representation to another swvice. which may use- the XML compiler/decompaer to decompile the XML 
repnsentation to reproduce the object, pcrfonn operations on the object at the request of the cKra^ 
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modifying the data). \ise the XML compilcr/decompfler to lecompfle the modified object into its XML 
representation, and send the XML representation of ffie object to the client 

In a third scenario, a service may use the XML compUer/dccompaer to compile a Java object into an 
representation of the object and send the XML representation to an object repository or store space. Tlie service 
5 may then send a message to a client infonning the client of the location of the XML representatioa IHe message 
may include a Universal Resource Identifier (URI) for the XML representation. The cUent inay then retrieve the 
XML representation of the object from the store space, and may u?e the XML compiler/decompiler to decompile the 
lepresentationtoreproducetheobject Alternatively, the cUent send the location of (he XML representation of 
the object to another service, along v«fli a request for operations to be performed on the object The oflier service 
10 msvthenretrieve1heXMLrepresentationfromthestorespace.metheXMLcompaer/d^^^^ 
XMLrepresentationtoreproducethe object andperformfterequested<^^ 

In a fourth scenario, a process (could be a cUent or service) may locjrte an object repository or store space 
in the distributed computing enviromnent by searching for and finding a service advertisement for the store space. 
The process may, during execution, create or obtam a plurality of Java objects. The process may use the XML 
15 compiler/decompfler to compile one or more of the objects into XML representations of the objects, and may send, 
as a cUent of the store space service, the XML representations of the objects to the store space to be stored for 
possible lata- access, or for access by otherprocesses. 

Security issues in die Decompflation of XML Representations of Objects 

Spaces, as described herein, may serve as a file system in the distributed computing enviromnent Security 
20 maybeprovidedforfilesinthesystemintheformofaccessrights. Access rights may be checked each time a file is 
accessed (opened, n^d, or written to). TTms. a method for providing file access security in the distributed 
computing environment may be desirable. TTris method may also be appUed to the XML representations of Java 
objects that may be stored in spaces and transmitted between cUents and services in the distributed computmg 
environment 

to one embodiment, a user of a client on a device m the distributed computing enviromnent may be 
identified and authenticated v^hen first accessing the client In one embodhnent. the user may supply a physical 
identification such as a smart card for identification and authorization. In another embodiment, a chaUeng^ 
response mechanism (such as user ID and password) may be used fi>r identification and authorization. Yet another 
embodhnent may use electronic identification such as a digital signature for identification and authorization. Any 
30 oflier method of identification and authorization may be used. 

Once identified and authorized, the user may then perform various operations on the cUent inclu^ 

accessmg one or more services in the distributed computing eijviroiiment During these operations, as described 
above, one or more objects may be created Oocally) or acquired from elsewhere (e.& 

object^ may be modified and may be compUed into XML representations of the objects and stored locally by the 
35 cUent or sent to a space service for (transitive or persistent) store. Some of the objects may be received from 
services (store services or other services) in the form of XML representations of the objects, which may be 
decompiled by the XML compflei/deconq)aer to recreate fteobjecfe on tiieclicHt 

In one embodhnent during the decompilation of the XKtt. representation of objects, each XML m«^ 

,nay be checked to verify that the user has access rights to the object If the user does not have die proper access 
40 rights, the XML compUer/decompiler may not decompUe die object for the user, in one embodiment, a security 
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exception may be thrown by the XML compner/decompaer. In one embodiment the user may be infomed of the 

access violation. 

Access right infoimation. such as the creator and access levels allowed (creator-only access, read only, 
•readAvrite. delete, copy, etc.) for the object may be embedded in the XML message(s) containing the XML 
5 representation of the object Access authorization may be determined during the identification and authorization of 
the user.. For example, the object may allow "read only" access for most users, and •Vead^mte'' accbss for the 
creator of the object If the user tries to access an object using readAvrite access rights, and flie user did not create 
. theobject,thedecompilationFocessnmydetectthisasanaccessviolation.andmaydisallowthe^ 

the user.' 

10 In one embodiment, when the user is done using the client, the user may log offor otherwise signal the user 

is finished with the cUent (e.g. remove a smart card). Objects created on the client by decompilation may be 
automatically deleted when the cUcnt detects that the user is finished- This may prohibit fiiture users firan 
intentionally or accidentally accessing the user's objects. In one embodiment, all objects created by deconipilation 
. may be deleted upon detecting that the nser is finished. In another embodiment, a method may be provided to store 
15 at least some of the objects created on the client per^istentiy (e.g. with access rights information), so that the client 
may later access the objects, or provide the objects to ofl»er users for access. 

In one ernbodiment, the user may have a "smart card-' or odier physical device to gain access to the 

Hie user may insert the smart card into ibc cHent device to begm the session. When the client is finished, the cKent 
may remove the smart card. The client may detect the removal of the smart card, and thus detect that the cUent fa 
20 finished, and may then proceed to delete objects created by decompilation of XML representations. 

XML-based object repositories 

In the distributed computing environment, processes (services and/or clients) may desire transient and/or 
persistent storage of objects such as XML schemas, service advertisements, results generated by services. XML 
25 repr^entations of Java objects and/or objects implemented m other languages, etc. Existing object storage 
technologies tend to be language and/or operating system specific. These storage systems also tend to be too 
complicated to be used with small footprint systems such as embedded systems. 

JavaSpaces in Jini is an exfating object repository mechanism. A JavaSpace may be only capable of storing 
Java objects and may be too large to be implemented in small devices with Ihnited amounts of memory . Each object 
30 in a JavaSpace may be serialized as previously described, and thus has the same limitations as previously described 

for the reflection and serialization techniques: 

A store mechanism may be provided for the dis1n^uted computing environment that may be heterogen^^ 

(not language or operating system dependent), that may scale from smaU to large devices, and that may provide 
tansient or persistent storage of objects. In one embodiment, the store mechanism in the distributed computing 
35 enviromnent may be implemented as an Internet Web page or set of pages defined iri the XML maricup language. 
XML pK)vides a language- and platform-mdependent object, representation format enabling Java and nonrJava 
software to store and retrieve language-independentobjects. . Since the store mechanfam is on^ 
all types and sizes (small to large) may access the store mechanisms. Web browsers may be used to view the store 
" mechanfam implemented as Web pages. Web search engines may be used to search for contents in th«5 store 
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mechanism implemented as Web pages. Inte^et adminktration mechanisms (eristing and future) and XML tools 
may be used to administer the XML-based store mechanisms. 

In one embodiment, the store mechanisms may be used to store objects created, represented or 
encapsulated in XML. Examples of objects that may be stored m the store mechanisms may inchide. but are not 
limited to: XML schemas. JOIL representations of objects (for example, Java objects compUed into XML . 
representatiohs as described above), service advertisements, and service results (data) encapsulated in XML. In one 
embodiment, to prevent miauthorized access of an XML object, an authorization credential such as a digital 
signature or certificate may be inchided with the XML object, and a cUcnt wishmg to access the XML object may be 
required to have the proper authorization credential to access the XML object to one embodiment, the store 
mechanism may be a space as described in the Spaces section herein. 

Store mechanisms may be services in the distributed computing environment A store mechanism 
implementedasaservicemaybereferredtoasa-stoteservice". A store service may publish an advertisement in a 
space. The space itself is an example of a store service. Some store services may be transient For example, a 
space service that stores service advertisements may be a transient store. Other store services may be persistent 
For example, a store service that stores results from services may be a persistent store. 

Figure 36 iUustrates a cUent 1604 and a service A 1606 accessing store medianisms 1600 and 1602 in the 
distributed computmg enviionm«m accorfii^to one embodhnent m 

is not intended to be limiting to the scope of this invention. In one embodiment, store mechanisms 1600 and 1602 
may eachbe an Internet Web page or set of Web pages defined in XML and accessible by a Web browser and other 
Intemettools. Store mechanism l600isatransientstorecapableofstoringobjectsimplementedusingXML..Store 
mechanism 1602 isapersistentstore also capable ofstormg objects nnpkmentedusingXML. Service A 1606 may 
publidi an XML service advertisement 1608.in transient store 1600. Persistent store may also publish an XML 
service advertisement m transient store 1600 (or on another transient store in the distributed computing 
enviromnent). At some pomt, client 1604 may requms fimctionaHty provided by Service A 1606. CUent 1604 may 
use a discovery and/or lookup service to locate service advertisement 1608. Client 1604 may then construct a 
message gate, as described herein, and begin commmucations with Service A 1606. Client 1604 may send one or 
more XML request messages to Service A 1606. Service A 1606 may perform one ormore fimctions in response to 
the one or more request messages. One or more of the Amotions performed by Service A1606 may pn^^^ 

to be provided to client 1604. 

For transient results 1610, Service A 1606 may encapsulate the results in an XML advert 

publish the advertisement 1612 in transient store 1600 (or on another transient store in &e distributed computmg 
. enviromnent). Service A 1606 may then notify client 16{H that the results 1610 are stored in adverti^ 
transient store 1600. or cUent 1604 may be notified by otha mechanisms as described here^ 
retrieve transient results 1610 from advertisement 1612. The advertisement 1612 may include an XML schema 
5 describing the formatting, contents, type. ete. of the transient resnhs 1610. The results msy be encapsulated m 
XML. For example, XML tags may be used to describe portions of the data: 

<XMLtagl> <datal> 
<XMLtag?> <data2> 
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For pereistent results 1618. Service A 1606 may use a service or other mechanism 
locate XML service advertisement 1616 for persistent store 1602, and tiins locate persistent store 1602 far storing 
persistent results. Alternatively, cUent 1604 may have previously located persistent store 1602 by locating its 
service advertisement 1616, and then may send a Universal Resource Identifier (UKI) for a storage location, for 
persistent results 1618 to Service A in an XML message. In one embodiment, persistent results 1618 may be stored 
in an Internet Web page or set of Web pages defined in XML and accessible by a Web browser. Service A 1606 
niay then store persistent results 1618 in persistent store 1602. Service A 1606 may flien pubUsh an XML 
advertisement 1616 for tiie persistent results 1618 in tnmsient store 1600 (or on anotiier transient store in flie 
distributed computing environment) and retmn tiie location of die advertisement 1616 to client 1604. The 
advertisement 1616 may include an XML schema describing tiie fonnatting, contents, t/pt, etc. of tiie persistent 
results 1618. Ihe results m^ be encapsulated in XML as previously desoibed. The advertisement may also 
mclude the URI of tiie persistent results 1618. Tbe client 1604 may then retrieve tiie advertisemait 1616 and use it 
to locate and retrieve persistent results 1618. Alternatively, Service A 1606 may not publisdi an advertisement for 
persistent results 1618, but instead may return a URI for flie pereistent results 1618 to client 1604 so client 1604 
may access tiie results wifliout looking up an advalisement. Note in some embodiments, tiie various advertisements 
shown in transient store 1600 may each be stored in different transient stores or spaces. 

Thus, store mechanisms m^ be implemented as XML*ased Internet Web pages in tiie distributed 
computing envnonment These store medianisms msy be implemented on a variety of devices in tiie envhxmment. 
and may provide service advertiseinents to aUow cUents (vrhich may be otiier services) to locate and use tiie store 
0 mechanisms. Existing and future Web and XML tools may be used to manage the store medianisms. The store 
mechanisms may store objects of various ^es implemented or encapsulated in XML. Clients on devices of 
substantially any size, fiom small footprint devices to supercomputers, m^ access &e store mechanisms to store and 
retrieve tiie various objects on tiie Internet The cUents may be Java or non-Java applications, as XML provides a 
language-independent storage format Thp transient or persistent object repositories may provide for a file system in 
:5 flie distributed computing environment and may include access checks and otiier security mechanism as described 
herein. 

Dynamically Converting a Java Object into an XML Document 

hi one enibodunent. tiie distributed computing environment may provide is mechanism to convert and 
represent an object class instance into an XML document In order to send representation of a class instance to 

SO anotiier service, tiie object may be converted and represented as an XML document In one embodiment, when 
receiving an XML document, a program may instantiate a class instance corresponding to tiie object represented by 
thedocument. to one embodiment, tiie objects may be Java objects, and flie progi^ may be a Java program. 

In one embodiment, an intermediary format m^ be used to rqnesent an XML document and may be 
dynamically processed to generate a class instance fliat represents tiie XML document TTie class may define a set of 

35 instance vmiables and "set and geT metiiods to access tiie instance variables. A corresponding XML document may 
be defined as a set of tags, wifli one tag for eadi mstance variable. When flie document is parsed, a hashatole 
representation may be constructed where tiie hash key may include tiie instance variable name and tiie vahie may 
include the instance variable value. If tiiere are multiple occmrences of a complex instance variable, an enumeration 
value may be stored m a hash table. In one embodiment, tiie process may be limited to only one level of complex 

40 ;^es for tiie instance variables, and tiie elements m^ be homogeneous. . 
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In one embodiment, a protected instance variable may be added to &e class definition Aat may include the 
name of the coiresponding class. TTie XML document representation may use the class name as the document type. 
Having the class name embedded in the docmnem may aUow dynamic instantiation of the right class instance when 
the object is reconstructed. 

5 In one embodiment, upon receiving a document, a class instance generator method m^ be used to extract 

the class ^e and to parse the document to generate the intermediary hash table representation. The generator 
method may instantiate a new class instance and may use the set methods to initialize the instance object froin the 
hash table vahies. In one embodiment, since the class type is defined and the hash table is generic, this process may 
be performed for any class that matches the above class definition. 

0 : In one embodiment, the reverse process m^ also be performed where a class instance may be processed 

into the intennediary hash table representation and a generator method may be used to produce anXML documrat 
fix)m the hash table representation. This process may also be made generic so that it may be performed for stay XML 
document that matches the above specification. 

This method is not intended to be limited to Java Class objects, and may be ^pUed to other computer- 

15 based objects, including class object instances of other programming languages. In addition, tiie method is not 
intended to be limited to XML representations of object instances; other representation fonnats including other data 
representation languages (such as HTML) may be substituted for XML. 
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XML-Based Process Migration 

The distributed computing environment may enable the distribution and management of distributed 
appUcations. For example, &e distributed conqiuting environment may inchide mobfle cUents that are dodcable 
with stations that provide monitors, printers, keyboards, and various other mput/output devices that are ^ically not 
provided on mobUe devices such as PDAs, ceU phones; etc. These mobUecUents may nm one or more appUcations, 
and may migrate from one station to another in the distributed computing environment Thus, one embodhnent of 
25 Ae distributed computing environment may provide a method for migrating an executing appUcatidn (process) wifli 
its entire current state fiom a mobile cUent on one node to the same mobile client or another mobile client at anofter 
node withm the distributed computing envnohment. 

In one embodhnent, an XML representation of flie state of a process executing on a cHent or service may be 
created. In one embodhnent, the XML representation ofthe state ofthe process may mclude a computation state of 
30 flie device and/or virtual machme on which the process is executing, wherein the computation state of the device 
and/or virtual machme comprises mformation about tiie execution state of flie process on the device and/or virtual 
madiine. A process state may mchide, but is not Ihnited to: tiireads, all objects referenced by tfie threads, Inmsient 
variable created during flie execution of flie process, objects and flieir data, etc. In one embodhnent, data 
describmg one or more leases representing grants of access to external services, obtained fiom spaces by flie 
35 . process, wherem flie one or more external services are external to flie device and/or virtual machme on v»*ich flie 
process is executing, may also be represented m XML and stored witti flie process state. Leases are described m 
more detail in the Leases section of this document 

Usmg XML and flie messagmg system as described herein, an XML representation of flie state of a process 
' may be moved from node to node wiflun flie distributed con^iuting envhonment, e.g. from node to node, on flie 
Internet The XML representation of flie state of a process may also be stored as an XML object m an XML-based 
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store mechanism as described above, and later retrieved from the store mechanism to resmne fee process execution 
on the same node or on a diferent node in the distributed computing environment In one embodiment, Ihe XML ■ 
object compilation/decompiiation process as described , herein may be used in creating (compiling) an XML 
representation of fee state of a . process and in regenerating fee state of fee process by decompiling tie XML 

representation of fee state of fee process. 

Using this medianism, an XML representation of fee state of a process may be stored in an XM^ 

store mechanism, such as a space, from an initial node. Subsequenfly. anofeer node inay locate the stored state of 
fee Focess, download fee state of fee Focess, and resume fee process from fee downloaded stored state at fee point 
at which it was executing when fee state was stored. Since fee process state is stored in an XML forinat, the tools 
and search facilities described herem to store, locate and retriieve XML objects in XML-based store mechanisms 
may be used to enable fee migration of fee process. An advertisement of fee stored XML iQ)resentadon of the state 
of fee Foccss may be published to aUow a client resuming fee process execution on fee same node or anofeer node 
to locate and access fee stored .sate. 

■riie XML representation of fee state of a process may be stored to an XML-based persistent store 
mechanism, and feus may provide a persistent snapshot of fee process. Tlis may be used as a mefeod to rcsmne 
process execution on a node after fee intemiption of fee process on fee node, for example, due to fee intentional or 
mnntentional shutdown of the node. An advertisement of fee stored state of fee process may be published to aUow 
clients to locate fee stored state in fee distributed computing environment In one emljodiment, to prevent 
unaufeorized access of an XML representation of fee stored state of a process, an aufeorization credential such as a 
. digital signamre or certificate may be inchided wife fee stored state, and a client wishing to resume a process from 
fee stored state may be required to have fee proper aufeorization credential to access the stored state. 

Figure 37 illustrates process migration using.an XML representation of fee state of a process according to 
one embodiment Process A 1636a may be execufeig on node 1630. Process A 1636a may be a client or service. 
At some point during fee execution of Process A 1636a, fee state of execution Of Process A 1636a may be captured 
and stored in an XML-encapsulated state of Process A 1638. The execution of Process A 1636a on node 1630 may 
tiien be stopped. Later, node 1632 may locate fee XM^encapsulated state of Process A 1638 and use it to resmne 
Process A 1636b on fee node 1632. Resmning Process A may include usmg the stored state 1638 to resume thread 
execution, recalculate transient variables, re-establish leased resources, and perform any ofeer fimctions necessary to 
resume execution as recorded in fee stored XML state of fee process 1638. 

The foUowmg is an example of usmg XML-based process migration in fee distiibuted computing 
ehviromnent; and is not intended to be limiting. A mobile client device may be connected to node 1630 and 
acecirting Pit)c«B A 1636a. The user of fee mobile cUent device may desire to stop execution of Process A 1636a 
on node 1630, .and to resume execution at a later time at anofeer (or fee same) node. In one embodiment, fee user 
. . may be prompted wife a query to determirie if fee user wishes to store fee state of Process A 1636a and resume 
execution later. If the user repUes in fee affinnative, fee XMLnmcapsulated state of the process may be captared 
and stored in pereistent store 1634. Later, fee user may connect fee mobUe computing device at node 1632. In one 
mbodiment, fee user may feen execute process 1636b and select a -Tlesmne from Stored State" option. The node 
• 1632 may feen search for and locate fee XML-encapsulated state of Process A 1638, download it, and use it to 
resmne Process A 1636b. Alternatively, fee process may itself know that it was "suspended" on anofeer node, and 
) may resume fixmi the stored state wifeout user input . • 
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Applications 

Technolo^es exist that allow a user to access network data fitjm remote 1^^^ 
appear as local data to the User, provided the user has access to a browser. However, such technologies do not 
provide an automatic infi^cturc to query netwoita near a client device's location. A mechanism for discovering 
information about networks and services near a client device may be desirable. For example, such a mechanism 
may be used to locate information about restauianls, weather, maps, traffic, movie mfoimation, etc wittun a certam 
distance (radius) of the cUent device, and to display desired mformation on the client device. An example of using 
this mechanism may be a cell phone that can be used to automatically locate services in a local environment, for 
example, in a movie theater to display the titles and show times of current features in the movie theater or iii a 
restaurant to view memi selections and prices. In the distributed computiiig enviromnent as described her^n. such a 
mechanism may be used to discover spaces including local information and/or services ptmhnate to flie client 
device. The mechanism may also be applied in otber distributed computing. enviromnents. for example, the Tmi 
system from Sun Microsystems. Inc; 

la one embodiment, a mobile client device may include Global Positioning System (GPS) capabiUty and 
wireless connection technology. lx)caldistnT)uted computing netwoiks may be provi For example, a city may 
provide a cilywide distributed computing environment Another example may be a shopping maU whh a local 
distributed computing environment A local distributed computing network may include a discovery medianism to 
aUow client devices to connect to the distributed computing environment and to discover services and data m tiie 
local environment For example, one or more devices m the enviromnent may include wireless comiection 
technology to aUow mobile client devices to connect to the network and to access the discovery mechanism via tiie 
XML messaging system as described previously. A local distributed computing enviromnent may inctode one or 
more spaces with advertisements for services and/or data to be made avaUable to mobile cUents. For example, a 
citywide distributed computing enviromnent may include spaces tiiat represent entities such as malls, movie tiieateis.. 
local news, local weather, traffic, etc. A space may include individual service and/or data advertisements for 
accessing services of and information about tiie entity flie space represents. TTie discovery mechanism may include 
a GPS location or locations of the local distributed computing envfromnent, entities represented by space services 
witiiin the environment, and/or the various services advertised in the spaces in tiie environment 

In one embodiment, wired connections may be provided to a locd distributed computing network. In Ibis 
. enviromnent. a user with a mobile cUent device may "ptag in" directty to the network using a wired comiection 
-docking station". Examples of wired ctmnections inchide. but are not limited to: Universal Serial Bus (USB), 
FireWire, and twisted:pair Internet hi one embodhnent, a docking station may also Fovide input/output 
capabiHties such as a keyboard, mouse, and display for the mobile client device. In tiiis embodiment, flie location of 
tiie mobile cUent device may be provided to tiie looki^ or discovery mechanism by tiie docking stetira. 

In one embodiiient, a mobUe client device may CMnect to a distributed computing network. As tiie user of 
flie mobile cUent device navigates wifliin wireless commmiications rangp of tiie disttibuted computing network, the 
mobile client device may constantiy. or at various intervals, provide a location Vector as mput to flie local lookup or, 
discovery mechanism. TTie mobile cUent device n^ obtain the location vector fiom a GPS system buik into 
associated wifli flie mobfle client In one embodiment, the cUent may send its location infonnation (e.g. via XML 
messaging) to a local service discovery mechanism, such as one of tiie space location mechanisms described herein, 
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For example, the cKent may nm the space discovery protocol specifying discoveiy for spaces offering services 
within a certain range of the cUenf s location, or fte client may instantiate a space search service to seaidi for spaces 
advertising services provided for the client's vicmity. 

As the mobile client device moves into a specified range of a space >yithin the dis«^ 

5 environment, the services and/or data stored in the space may be made available to the mobfle cUent device. In 
embodiments where the client device regularly provides its location to a discoveiy mechanisni, local services and/or 
data liiay automatically be made available to the cUenfs user. In one embodiment, the user of the mobile cUent 
device may determine the specified range of a space. For example. Ae user may choose to display aU restaurants, 
within one mfle of a current location. Alternatively, the raiige may be specified m the configuration of the local 
10 distributed computing netwodc. For example, a citywide distributed computing network may be configmxsd to 
provide its services to all users within 1hi«e miles of the cily limits. In one embodiment, visual indicators, for 
■ example icons, representing the various services and/or data offered by fte space may be displayed on thie mobile 
client device. The cUent may then access one or more of the displayed services and/or data. In one embodhnent. 
information fiom two or more spaces may be displayed simultaneously on the mobile client device. In one 
15 embodiment, the user may select what services and/or data are to be detected. For example, m a shopping mall, a 
user with a mobile cUent device may choose to display all shoe stores m the malL 

In one embodiment, executable code and/or data used m the execution of the code may be do^ 

the mobile client device to allow the user to execute an application provided by a service in the space. For example, 
moviegoers with mobile cUent devices may download interactive movie reviews fi-om services in a space for the 
20 movie theater, and may thus perforin real-time feedback about the movie they are watching. In one embodiment, an 
XML object compilation/decompilation mechanism as described elsewhere herein may be used to compile the code 
and/or data to produce XML representations of the code and/or data, and to decompile the XML repr^ 
reproduce the code and/or data on the mobile client device. In one embodhnent, an executable version of a process, 
may previously exist on the mobile client device, and a stored state of the process may be downloaded tothe mobUe 
25 client device to aUow the user to execute the process using the stored state. In one embodhnent, an executable 
V version of a process may previously exist on the mobile. cUent device, and data for the process may be downloaded 
to the rriobilecUent device. Forexample. data inay be downloaded for viewing with a viewer program on the mobfle 
client device. In one embodhnent. an executable version of a process, mcluding the code and data for executing the 
process/maybe downloaded for execution on the mobile cUent device. In one embodhnent, the service may execute 
30 the appUcation remotely on behalf of the mobile cHent device, and the service and cUent may pass to each other 
XML messages including data and optionally XML schemas describmg the data. In one embodiment, some code 
may be executed on the service and some on the client For example, the service may execute code to perform 
operations on a set of data such as numerical calculations. Tte mobile client device may execute code that may 
display portions of the data passed to the cUent from the service m XML messages and allow the user of the mobile 
35 cUent device to enter and/or select data and send the data to the service for performmg one or more operations on 
the data. 

In one embodiment, a mobile chent device may be connected to two or more services in. the distributed 
cpmputmg network shnultaneously. Hie services may be used independently or m conjunction for performing a 
series oftasks. For example, one service may be used by a remote clientdevice to locate and/or perform opeia^ 
40 on a set of data, and a second service may be used to print the set of data. 
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Figure 38 iUusti^ a mobile client device accessing spaces in a local distributed computing network, 
according to one embodiment A user of GPS^nabled mobUe computing device 1700 may move into proximity of a . 
local distributed computing environment The mobile cUent device 1700 may provide its location provided by GPS 
1702 to one or moi« discove^r mechanisms 1706 in the local distributed computing network. TTie discovery 
mechanism 1706 may use the provided GPS location of the mobile cUent device and piedetennined locations of 
spaces within the enviromnent to determine when the user moves within a specified range of one or more spaces or a 
vicinity served by one or more spaces within the enviromnent . For ciample. discovery mechanism .1706 may 
. determine that mobile client device 1700 has moved within range of space 1704. Discovery mechanism 1706 may : 
then provide one or more advertisements 1710 from space 1704 to the mobfle client device 1700. Alternatively, 
discovery mechanism 1706 may provide a Universal Resom-ce Identifier (URl) for space 1704. or for one or more 
advertisements in space 1704. to mobUe cUent device 1700. Icons representing the various services advertised by 
service advertisements 1708 and/or data represented by content advertisements 1710 may then be displayed on 
mobile client device 1700. Tlie user nuy then select one or more of the advertised services and/or data for 
execution and/or display on the mobCe cUent device. TTie mobile computing device 1700 may establish a wireless 
5 comiection with the device offering the service and communicate with the device to execute.the service usinglhe 
XML-based messaging system as previously described herein. Alternatively, the user of the mobUe computing 
device 1700 may comiect the device at a docking station. Tie location of the dockmg station may have been 
discovered by &e user using the lookup or discovery mechanism 1706. and spaces containing advertiseinenls for the 
docking stations to discover the location and availability of docking stations within a specified range of the user. 
»0 Discovery mechanism 1706 may also detect when mobile cUent device 1700 moves into a selected range of 

space 1714. Tte various service advertisements 1718 and content advertisements 1720 may then be made available 
to the user of the mobUe cUent device 1700. When the mobile client device moves out of the specified range of one 
of the spaces, the advertisements offered by tiiat space may be removed fiom the mobile client device 1700's. 
dispk^. 

25 In one embodiment advertisements on a srace may inctade location inforrnation for the services or 

that they provide. Hus, discovery mechanism 1706 may determme when mobile cUent device 1700 moves withm a 
. specified range of a particular service advertised on space 1718. and may provide (or remove) the service 
advertisement based upon the location of the mobile cUent device 1700. 

Computing devices aK shrinking whfle at the same time gaining power and fimctionality. Storage devices. 
30 CPUs. RAH I/O ASICS, power suppUes, etc. have been reduced in size to where small mobUe client device may 
include much of the fimctionality of a fidl-sized personal compiiter. However, some components of a computer 
system are not easily shrinkable because of the human factor and other fectors. TTiese components include, but are 
not limited to: keyboards, monitors, scanners, and printers. The limits on reducmg the size of some components 
inay prevent mobile client devices fixim truly assuming the role of personal computers. 
35 In one embodiment, docking stations may be provided that allow users with mobfle cHent devices to 

comiect to and use components that are not available on the mobile cKent device because of human or other fectors. 
For example, docking stations may be provided in public places sudi as airports or Ubraries. TTie «|6ckmg stations 
.may. provide monitors, keyboiffds. printers or other devices for users with mobfle client devices. In one 
embodiment the docking stations may not folly fimction without help fimn a real computing device such as a mobfle 
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client device connected by a user. The docking station may provide services such as various n^)ut/output functions 
to the client using tiie computing power of tiie mobile client device. 

A docking station may provide one or more connection options to a mobile client device. The connection 
options may include wireless connections and wired connections. Examples of wireless connections include, but are 
not limited to: infrared such as IrDA and wireless network connections similar to diose provided by a network 
interface card (NIC) in a notebook computer. Examples of wired connections include, but are not limited to; USB, 
FireWire, and twisted-pair Ethernet 

A mobile client device may discover the location of docking stations using a method substantially similar to 
that described above for mobile client devices. The location of one or more docking stations m a local distributed 
computing network may be discovered using a discovery mechanism to discover spaces with advertisements for 
docking stations, the mobile client device may provide a location to the discovery medianism. In one 
embodnnent, the discovery mechanism or a lookup mechanism may return tiie location of one or mwe doddng 
stations closest to the location of the mobile client device. Altematively, tiie discovery mechanism or lookiq> 
mechanism may return a URI of the space containing the advertisements for tiie docking stations, and the mobile 
client device may then connect with the space to proyide the location of the one or more docking stations near tiie 
device. In one embodiment, the mobile client device may supply mformation to the lookup or discovery mechanism 
to specify requirements such as monitor resolution, screen size, graphics capabilities, available devices such as 
printers and scanners, etc. In one embodiment, information about the one or more docking stations m^ be supplied 
to the user on the mobile client device including availability (is another user using tiie docking station), components 
and capabilities of the various dockmg stations. 

When a xiser approaches a docking station, a claiming protocol may be initiated. When the dockmg station 
accepts the claun, secure input and ou^ut connections may b^ established between the mobile client device and the 
dockmg station. Altematively, the user may select the docking station from one or more docking stations discovered 
using the lookup or discovery mechanism displayed on the mobile client device. When the user selects the docking 
station, tiie claiming protocol may be initiated to give the user secure, exclusive connection to the docking station 
for the duration of the claim, A dockmg station release method may also be provided to allow tiie user to terminate 
the session on the docking station and release the docking station for use by other users. In one embodnnent, the 
claiming protocol may be a lease on the dockmg station service as described previomly herem. 

Figure 39a illustrates a user of a mobile device discovering tiie location of docldng stations according to 
one embodiment Mobile client device 1750 may connect witii discovery mechanism 1756. Mobile client device 
1750 may provide a location obtained usmg GPS 1752 to discovery mechanism 1756. Mobile client device 1750 
rbtay also provide docking station requkements to discovery mechanism 1756. Discovery mechanism 1756 may 
search one or more spaces 1754 for advertisements for docking stations 1758 tiiat meet tiie requirements of mobile 
client device 1750. In one embodiment, a lookup or discovery mechanism may locate one or more dockmg stations 
within a specified range of mobile device 1750 by comparing location information stored m advertisements 1758 
with the supplied location of mobile device 1750. Discovery mechanism 1756 may then provide tiie location of one 
or more docking stations within a specified range of mobile client device 1750. Altematively, discovery mechanism 
1756 may locate a nearest dockmg station to mobile client device 1750 and provide the location to mobUe client 
device 1750. 
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Figure 39b illustrates a mobile client device 1750 connecting to a docking station 1760, according to one 
embodiment In one embodiment, the user miay move mobile client device 1750 into wireless range of docking 
station 1760 and make a wireless connection to the docking station 1760. In another embodiment, the user may 
establish a wired connection to docking station 1760 by connecting one or more cables between docking station 
1760 and mobile client device 1750. In one embodiment, the user of the mobile client device 1750 may establish a 
claim to the dockmg station 1760. The claim may establish secure, exclusive rights to the docking station for the 
duration of the connection. In one embodunent, the claim mechzmism may be a lease mechanism for a resource (the 
docking station) as described previously herein. In one embodiment, a user may be billed for use of the docking 
station. For example, the user may supply a credit card number as part of the process of claiming a docking station. 
Refer to the description of bill gates in the Message Gates section herein. Once connected, the user may use the 
various fecilities provided by the dockmg station 1760 such as keyboard, monitor, printer, etc. Docking station 
1760 may also include a connection to a local distributed computing network and thus may provide the user of the 
mobile client device 1750 connected to the docking station 1760 with discovery services for locating service and 
content advertisements on other devices within the iietwork, allowing the user to locate and use various services and 
content in the distributed con^)uting enviroimient as described previously herein. 

When finished, the user msy disconnect the mobile client device 1750 from the docking station 1760. In 
one embodiment, a docking station release mechamsm may automatically be initiated when the mobile client device 
1750 is disconnected from the docking station 1750. The release mechanism may clear any claim on the docking 
station 1760 established by the user of the mobile client device 1750. In one embodiment, the release mechanism 
may notify the discovery mechanism 1756 and/or docking station advertisement 1758 that the doddng station is 
available. 

In one embodiment, a user may connect a mobile client device to a docking station without using the 
discovery mechanism. For exaDq)le, a user in an airport may visually detect a docking station and connect a mobile 
client device to it. Another example may be a library providing a docking station room with a plurality of docknig 
stations for use, where users may access any of the docking stations that are available. 

Small Footprint and/or Embedded Devices 

Simple embedded or small foo^rint devices may have limited ampimts of memory for storing and 
executing program mstructions. A simple embedded device may need to understand a limited set of control n:^uts 
for mitiating fimctionality of the device and outputs for reporting the status of the device. An example of a shnple 
embedded device is a "smar^' switch (such as a light switch) with embedded circuitry for controlling the switch and 
thus the device controlled by the switdL The smart switch may only need to understand two control requests 
(change the state of the device, request the state of the device) and to send one status message (the state of the 
device). The smart switdi may manage the device to which it is connected by receiving its control requests from 
one or more control systems and reporting status messages to the one or more control systems. 

In one embodiment, the distributed computing environment may provide a frameworic (protocol) for 
including small devices that may not have the resource footprint (such as memory) necessary to iinplement the full 
protocol of the distributed computing environment In one embodnnent, an agent may be provided as a bridge 
between the small device-capable protocol and the frill protocol. The agent may perform the frill protocol discovery 
for the small device, so the device may not be required to implement the fiiU discovery protocol and service 
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acdvadoo. In one embodiment, the small device may only need to send service-specific messages. In one 
embodiment, these messages may be pre-cooked on the small device, so the smaD device may only have to send 
messages that are part of the service activation to the agent TTie agent may perfonn the service activation via the M . 
protocol to the service and forward incoming message from the device to the. service, and/or may forward r^pUes 
. from the service to the client Thus, the agent may act as a service comiector for the smaU client. 

In one embodiment of the distributed computing eaviromnenl. an embedded device may be configmed to 
xsceive a specific set of control requests in the form of XML messages and to send a spedfic set of^ 
to make requests, report stiitus. etc. In one embodiment, a control system may be configmed to manage a variety of 
devices by sending XML request messages specific to each device or category of device that it controls and by . 
» . receivingXMLmessagesfromthedevices. Inoneembodiment.oneormoreXMLschemasmaybeusedt^ 

an embedded device's specific set of XML messages; the schema may be used by the embedded device and/or the 
control system in sending and receiving XML messages. 

An embedded device may inctade a "thin" implementation of the XML m«sagmg system as previously 
described herein that supports the specific set of messages for controlling and monitoring the simple embedded 
5 device. TTie implementation of the XML messaging system may be taUored for use v*h small footprint, shnple 
embedded devices, and thus may fit in the limited memory of the small footprint devices; m one embodiment, the 
XML messaging system may be hnplemented in a small fi>otprint wito a virtual machine targeted at small finrtprint 
embedded devices (e.g. KVM). A networking stack (to support the transport protocol for commmiications with one 
or more control systems) may be associated with the virtual machine and the XML messaging layer may "sit on top" 
20 of the networking stack. It is noted that this implementation of the messaging system may be used in other devices 

than small footprint or embedded devices. 

In one embodfanent static or pre-generated messages may be used for requests fiom control system 

embedded devices. n,e static messages may be precompfled and stored in the embedded devices. An incoming 
message may be compared with the stored static messages to find a match for tiie message and thus to perform the 
25 fimction requested by flie message, thus reducing or eliminating the need for code to parse incoming messages. 
Outgoing messages may be read directiy from tiie stored static messages, thus reducmg or eliminating tiie need to 
dynami<ally compile outgoing messages. Hius. static messages may be used to reduce tiie code footprint of the 
messaging layer in embedded systems: For example, static Java objects (Java op codes) may be used for request and 

Status messages. 

30 Figure40amustralesanembodunentofembeddeddevicesl804aandl804bcontroUedbyacontt^^ 

1800.accordmgtooneembodnnent Control system 1800 may be networked with the devices 1804a and 1804b it 
controb in any of a variety of ways. TTie network 1810 miv be wired (Eflietnet, coaxial, t^^ 
etc.) and/or wirtiless (frDA, microwave, etc.). Li one embodiment, embedd«^ 

a thin implementation of the XML messaging system for communicating with control system 1800 over netwoik 
35 1810. Contiolsysteml800mayhaveanunplementationofflieXMLmessagn.gsystemforsend^ 

receiving responses from embedded devices i804a and 1804b. In one embodiment, control system 1800 may 
include software and hardwue configured to present an intetfece t^ 

remotely- control tiie embedded devices 1804a and i804b. In one embodiment, control system 1800 may inchide 
software and/or hardware for automatic control of embedded devices 1804a and 1804b. 
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In one embodiment, embedded devices 1804a and 1804b may be part of another environment The 
devices may not support the message passing model implemented by the distributed network environment For 
example, the devices may be nodes in a networked automation and control system such as a LonWoiks network. 
Control system 1800 may include a control system hardware and/or software for controlling devices ha the other 
envkonment Control system 1800 may serve as a bridge between the distributed computmg envnonment and the 
other environment The distributed computing environment may also provide a metbod or methods to map existing 
device discovery protocols for discovering the devices for access from the distributed network envfforiment 
Bridgmg and wrapping protocols are furAer described herein m Ae B 

Control system 1800 may be connected remotely or locally to one or more other systems in the distributed 
computing environment Figure 40a shows control system 1800 connected to client 1806 via the Internet 1802. 
Client 1806 m^ indirectly request the status of, and send control requests to, embedded devices 1804a and 1804b 
througfi control system 1800. Thus, control system 1800 msy serve as a proxy or bridge for embedded devices 
1804a and 1804b. See ihe Bridging section herem. To enable sophisticated communicatioii between the client 1806 
and the control system 1800, the client and the control system may have different unplementations of the XML 
messaging system than the thm implementation on the embedded devices 1804a and 1804b, In one embodhnent, 
client 1806 may include software and hardware configured to present an interfece to allow a user of client 1806 to 
(Ksplay the status of and remotely control the embedded devices 1804a and 1804b. In one embodimait, client 1806 
must present the correct authorization credentials to control system 1800 to enable the cHent 1806 to access 
embedded devices 1804a and 1804b. In one embodhnent, client 1806 may be granted access at different levels. For 
example, cUent 1806 may only be able to view the status of embedded devices 1804a and 1804b but not be aOowed 
to remotely control the devices. In one embodiment, control system 1800 may be a service, m^ have a service 
. advertisement published in the distributed computing envuonment, and tiius may be accessed by cUent 1 806 using 
the cUent-sendce method as described previously in this document In one embodhnent, client 1 806 may be able to 
view the status of, and to remotely control, control system 1800. 

Figure 40b illustrates cUent control systan 1808 connected via the Internet 1802 to embedded devices 
1804c and 1804d, according to one embodiment In one embodhnent, embedded devices 1804c and 1864d may 
mclude a thm unplementation of the XML messagmg system for communicating with client control system 1808 
over the Internet 1802. Client control system 1808 may have an implementation of flie XML messagmg system for 
sending requests to and receiving responses from embedded devices 1804c and 1804d In one embodhnent, client 
control system 1808 may include software and hardware configured to present an mterfece to allow a user to displ^ 
the status of and remotely control the embedded devices 1804c and 1804d. In one embodiment, cUent control 
system 1800 m^ include software and/or hardware for autoniaticcoiitrol of embedded device 1804c and 1804d. 

A difference between Figure 40a and Figure 40b is that, in tiie embodhnent illustrated in Figure 40b, the 
embedded devices 1804c and 1804d m^ be accessed by one or more clients in tiie distributed computing 
eiiviix)nmait without requiring a proxy (e.g. control system). Embedded devices 1804c and 18044 may mchide 
services for accessmg the functionality of the devices, may have published service advertisements m the distributed 
conQ>uting environment, and thus may be accessed via the client-service method as described previously in tiiis 
document 

The distributed computing eiivironment may mclude a medianism fi^r a resource-hmited client to retrieve 
Universal Resource Identifier (URI) addressed resources. For example, a cHent tiiat is only cap^le of sendmg and 
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receiving messages via an IrDA connection m^ not be able to establish a URI connection to retrieve results from a 
results space. In one embodiment, a service may be provided as a bridge between the client and the URI resource.. 
Hie bridge service may interact with the client via XML messages to gather input parameters. The follovdng is 
mcluded as an example of XML mput message syntax and is not intended to be limiting in airy way: 
<type name=*HttpGef> 

<element name="urlstring" type==^string"A> 

</type> 

Then, outside the distributed computing environment, the bridge service may establish a URI connection 
and retrieve die resource. The resource may then be encapsulated as a payload in.one or more XML messages and 
sent to the client by the bridge service. 

The following illustration of one possible use of embedded devices witii thin in^lementations of the XML 
messa^g system is included for exemplary purpc^es and is not intended to be limiting. A building m^ mclude a 
pluraUty of electronic devices tiiat consume energy (e.g. Ughts, air conditioners, oftice equipment), and thus may 
require a system for maintaming an optimum energy consumption level The pluraHty of devices may each include 
an embedded device for controlling the electronic devices. The embedded devices may include Ae diin 
implementation of the XML messa^g system. One or more control systems may be coiq)led to die devices in a 
networic, for example, a building LAN or even the Internet A control system may store and execute a bmlding 
management software package and an implementation of tiie XML messaging system configured to be used by the 
) software package for monitoring and controUing the devices. The control system may accqrt input from users, and 
may display and otiierwise output status mformation for the building energy consumption system, including status 
information for each of die plurality of devices. Energy consumption m^ be monitored by recervmg XML status 
messages from each of tiie plurality of devices. When energy consumption levels need to be adjusted, XML control 
messages may be sent to one or more of tiie devices to cause tiie energy consumption to change. 

i5 

Implementing Services 

In one embodiment, tiie distributed computing environment may provide a mechanism for in^lementing 
services as servlets. The mechanism may provide fonctionaUty for developing services for tiie distributed 
computing environment 

JO In one embodiment, an Application Programming Intexfece (API) may be provided tiiat provides tiie 

fanctionaHty to allow tiie service to be initialized and registered in a space. In one embodiment, die API 
be used to invoke tiie initialization of tiie service and to generate an initialization status page, for example, an 
HTML page, tiiat may define the status of die service. Ausermay access tiie status oftiie service by accessing tiie 
status page from a browser. In one embodiment, tiie API m^ be used to process iricoming messages and to 

35 generate documents m response to the messages. 

An embodiment of tiie servlet mechanism may provide several functions inchiding, but not limited to: 
• . Management oftiie client connection to tiie service (unique session ID) 
» Management of an activation space tiiat may be used to store results advertisements 
Management of leases on connections sessions and results in activation ^aces • 
40 o. Garbage collection of sessions and results 
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« Authentication of clients 

« Generation of client capabilities on a per session basis 
In one embodiment, the distributed computing environment may provide a service cascading mechanism by which 
new, complex ser\aces may be constructed from other existing services. For exanq)le, from a JPEG-to-?ostScript 
transformation service and a print service, combining the transformation and print service ma/ create a third 
cascaded service. In one embodiment, two or more services may be combined into a complex service by defining 
access methods of the two or more services as tiie access methods of the cascaded service. The foUowing service 
advertisement for a cascaded service is included for exemplary purposes 
and is not intended to be limiting in any way: 

<Service> 
<^ame>Complex Servicedname> 
<ID>.»</n» 

<descriptioii> </descriptioD?" 

<AccessMetfaod> 

<;AccessMethod> 

<naine>com-transcode. jpg2psdname> 

<implementatioD>httpy/www.transcodexom/software^pg2psoardi^ 
<7AccessMethod> 
<AccessMethod> 

<name>com,printeritpPrint<yname> 

<implemenMiGn>http://www.printerxoni/software/fippriatjar</m^ 
</AccessMe1hod> 

<;/AccessMetho<> . 

<yService> 
Conclusion 

Various embodiments may further include receiving, sending or storing instructions and/or data 
implemented in accordance with tiie foregoing description upon a carrier medium. Generally speaking, a carrier 
medhnn may include storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, 
volatile or non-volatile media such as RAM (e.g. SDRAM, RDRAM, SRAM, etc.), ROM, etc. as well as 
transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication 
medium such as network and/or a wireless link. 

Various modifications and changes m^ be made as would be obvious to a person skilled in the art having 
the benefit of this disclosure. It is intended that tiie invention embraces all such modifications and changes and, 
accordingly, the specifications, appendices and drawmgs are to be regarded in an illustrative rather than a restrictive 
sense. 
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WHAT IS CLAIMED IS: 

L A method for accessing a service in a distributed computing environment, comprising: 
a client locating a first service within the distributed computing environment; 
5 the cUent requesting a capability credential to aUow. the cUent access to a portion of the first service's 

. capabilities, wherein said requestmg a capability 

desired capabilities; 

. theclientreceivingsaidcapabiUtycredentHvvhereinsddcapabimyc^^^^ 
Ihe right to use said portion of the first service's c^bflities; and 
10 the client using said capabiUty credential to access one or more of said p^^^ 

capabilities. 



2. 



•me'inethod as recited in claim 1, wherein said requesting a capability credential comprises the client 
sending a capability credential request message, wherein said capability credential request message comprises an 
15 identificationofsaidfirstserviceaiidanindicationofthesetofdesiredcapabilities. 

3. The mediod as recited in claim 2, whendn said identificatian of said first service comprises a Universal 
Unique Identifier (UUID). 

20 4. The method as recited m claim 2, wherein , said capability credential request message if formatted in 
extensible Maricup Language (XML). 

5. The method as recited in claim 2, further comprising: 

the client receiving an advertisement for.the first service. wh«^in saidadvertisement d«^^ 

25 of flie first service's capabilities; and 

wherein said indication of the set of desired capabiUties comprises an indication of said advertisement 

6. Tie method as recited m claim 5. wherein said indication ofsaida(h:eitbement is said ad^ 



30 7. 



The method as recited in clann 5, wherein said indication of said advertisement is a Uniform R«onrce 
Identifier (URT) to said advertisement 

8. Tlie method as raited in claim 5. wherein sdd advertisement descnT)esaU of the first ser^^ 
and wherein sdd mdication of said advertisement m said capabmty credential requ^ 
3 5 advertisement edited to describe only said set of desired exilities. 

• 9. ihe mefliod as recited in claim 5, wherein said advertisemerrt is a protected advertisement that describes 
the first service's capabilities bm does not provide an interfece to tije first service's 

40 
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10. The method as recited m claim 1, further comprising; 

. the client receiving a protected advertisement for the fffst service, wherein said proteaed advertisenient 
indicates an address for sendmg said capability credential request message to; and 
wherein said requesting a capability credential comprises the client sending a capabiHty credential request 
' message to said address indicated in said protected advertisement 

11. The mediod as recited in claim 10, wherein said address indicated 

authentication service, wherein said sending a capability credential request message comprises sending said 
capability credential request message to said authentication service, the method further comprising the 
authentication service sending a credential request response message to the cUent m response to said capability 
credential request message, 

12. The method as recited m claim 11, wherein said credential request response message includes said 
capability credential, wherein said receivmg said capability credential comprises receiving said capabiHty credential 
fi-om said authentication service in said credential request response message. 

13. The metibod as recited in claim 1, further comprising: 

die client receiving a protected iadvertisement for the first service, wherem said protected advertisement 

indicates an authentication service; and 
wherein said requesting a capability credential comprises the client requestmg a capabiHty credential from 

said authentication service. 

14. The method as recited in claim 13, the method further con^jrising: 

said authentication service detennining a level of tiie first service's capabiHties that the cHent is authorized 
to use; 

said authentication service generating said capability credential according to said level and said set of 
desired capabilities; and 

said aiithentication service sendmg said capabiHty credential to the cHoit, wherein said portion of the first 
service's capabiHties tiiat said capabiHty credential indicates that the cHent has a right to use is no 
more tiian said set of desired capabilities. 

15. The method as recited in claim 14, wherem said portion of the first service's capabiHties that said 
c^abiHty credential indicates that the cHent has a right to use is the lesser of sdd level of the first service's 
capabiHties that the cHent is authorized to use and said set of desired CE^Kibilities. 

16. The method as recited in claim 1, wherein said using said capability credential to access one or more of 
said portion of die first services capabiHties comprises die cHent sendmg a message to the first service to access a 
first capabiHty, wherein the message includes said capability credaitial, the method further comprising the first 
service authenticating said capabiHty credential received in tiie message to verify that the cHent has the right to use 
said first capabiHty. 
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17. A client device, comprising: 

a connection to a distributed computing environment 

an interface coupled to said connection and configured to locate a first service within the distributed 
computing environment; 

wherein the interface is fiirftter configured to request over the connection a capability credential for a set of 
desired c^abilities to allow the client on the cHent device access to a portion of the first service's 
capabilities; 

wherein the interface is fiirther configured to receive over the connection said cap^^ 

said capability credential indicates that the client has the right to use said portion of the first 
service's capabilities; and 

wherein the interfece is further configured to use said cq)ability credential to access one or more of said 
portion of the first service's capabilities. 

is. The client device as recited in claim 17, wherem the interfece is configured to request a capability 
credential by sending a capabiHly credential request message, v^erem said capability credential request message 
comprises and identification of said first service and an indication of the set of desired capabilities, 

19. The client device as recited in clann 18, wherein said identification of said first service conqnises a 
Universal Unique Identifier (trUID). 

20. The client device as recited in claim 18, wherein said c^abiUty credential request message if fonnatted in 
extensible Maiicup Language PML). 

21. The client device as recited in claim 18, A^erein die interface is fimher configured to receive an 
advertisement for the first service, wherein said advertisement describes the portion of die first service's capabiUties, 
and wherein said indication of the set of desired capabilities comprises an indication of said advertisement 

22. The client device as recited in claun 21, wherein said mdication of said advertisement is said advertisement 
itself 

23. Ihe client device as recited m clann 22, wherem said mdication of said advertisement is a Uniform 
Resource Identifier (URI) to said advertisement 

24. The client device as recited m claim 21, \^erem said advertisement describes all of the first service's 
capabiUties, and A^erein said indication of said advertisement in said cq>abihty credential request message m a 
version of said advertisement edited to describe only said set of deshed capabilities. 

25. The client device as recited in claun 21, \^erein said advertisement is a protected advertisement that 
describes the first service's capabilities but docs not provide an interface to the first service's cq)abilities. 
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26. -me cUent device as recited in claim 17, wberein ttie intofece is further configured to receive a protected 
advertisement for Jhe first, service, whereia said protected advertbement indicates an address for sending said 
capability credentikl request message to. and wherein the interfece is configured to request a.capabUity credential by 
sending a capabiUty credenM request message to sdd address indicated in said protected advertis 

5 ■ ■ ■ ■• 

27. Hie cUent device as recited in claim 26, wherein said address indicated in said protected advertisement is 

for an aulhentication service, wherein said sending a capabiUty credential request message comprises sending said 
capability credemtial request message to said authentication service. 

10 28; The client device as recited m claim 27, wherein interfiice is configured to receive, said capability 
credential &om said authentication service in a credential request response message, 

29. The client device as recited mclahn 17, wherein flie interfece is finther configure to: 
receive a protected advertisement for the first sendee, vAerehi sdd protected adverts 

15 . . authentication service; and 

request a c^abiUty credential by requesting a capability credential Aom said airthentication service. 

30. The cUent device as recited m claim 29, wherem said portion of the first service's capabilities that said 
capability credential indicates that the client has a riglit to use is the lesser of said level of the first service's 

20 capabilities that the cUent is authorized to use and said set of desired capabilities. 

31. TiiecUent device as recited in claim 17, wherem the interfece is configured to use said capabihtycredentid 
to access one or more of said portion of the first services capabilities for said cUent by sendmg a message to the first 
service to access a first capability, wherein the message includes said.capability credential so that ihe first service 

25 may authenticate said capability credential received in the message to verify that tiie cUent has tiie right to use said 
first capability. 

32. The client device as recited in claun 17, wherein said interfece comprises one ormore processes executable 
on a processor within the client device. 
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33. A carrier , medium comprismg program instructions, whosin tiie program instructions are compute^ 
executable on a client device to iinplement: 

locating a first service witiiin the distributed computing aivironment; 

requesting a capability credential to allow a client on tiie client device access to a portion oif flie first 
service's capabilities, wherem said requesting a cqiabilily credratial conges tiie client 
indicating a set of desired capabilities; 

receiving said capability CTedehtial. wherem said capability credential mdicates tiiat tiie client has tiie ri^t 
to use said portion of tiie first service's capabilities and . 

using sdd capabihty oedoitial to access one or more of s^d portion of tiie first service's capabilities. 
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. 34. The earner medium as recited in claim 33. \vlierein said requesting a capability credential comprises the 
client sending a capability credential request message, wiierein said capabUity oedeijtial request message comprises ' 
an identification of said first service and an indication of tiieset of desired capabili^^ 

5 35. The earner medium as.recfted in claim 34, wherein said identification of said firsts 
UnivecsalUnique Identifier (UUID). 

36. lie carrier medium as recited in claim 34. wherein said capabiUty credential request messa^^^ 
in extensible Markup Language (XML). 

10 

37. TT,e earner meditnn as recited in claim 34. wherein the program instrucd^^ 

the client device to fiirther implement 

receivmg an advertisement for the first servi*. wherein said advertisement describes the portion of the first 

service's capabilities; and 
xvherein said indication of the set of desired capabiKties comprises an mdiratim of said advertiser 

38. The carrier medium as recited in claim 37, wherein said indication of said advertisement is said 
advertisement itself. 

20 39. The cairier medium as recited in claim 37. wherein said indication of said advertisement is a Uniform 
Resource Identifier (URI) to said advertisement. 

40. The carrier medium as recited mclahn 37. wherein said .advertisement describes all of the first sem^^ 
capabilities, and wherein said indication of said advertisement in said capability credential request message in a 

25 version ofsaid advertisement edited to describe only said set of desired capabilities. 

41. The earner medium as recited m claim 37. wherein said advertisement is a protected advert^ 
describes the first service's capabiMes but do« not provide an interface to the first ser^ 

30 42. The carrier medimn as recited m claim 33. wherein the program instructions are computer-executable on 
the client device to fiirther unplement 

" receiving a protected advertisement for the first service, wherein said protected advertisement indicates 'an 
address for sending said capability credential request message to; and 
whwein said requesting a capability credential comprises tiie cUent sending a capability credential request 
35 . message to said address indicated in said protected advertisement 

43. The carrier medimn as recited m clami 42, wherein said address mdieated m said protected advertisement 
fa for an authentication service, wherein said sending a capabiUty credential re^ 
cq)ability CTedential request message to said authentication service. 

40 
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44. TTie carrier medium as recited in claim 43, wherein said receiving said capability CTedential comprises 
receiving said capability credential fix)m said authentication service m a credential request response message. 

45. Tie carrier medium as recited in claim 33, wherein the program instructions are computer-executable on 
the client device to further hnplement 

receiving a protected advertisement for die first service, wherein said protected advertisement indicates an 
authentication service; and 

wherein said requesting a capabiUty credentid comprises the client requesting a c^ability credential from 
said authentication service. 

46. Iliecairier medium as recited in clahn 45, wherem said portion of ti^ 

capability wedential indicates that tije client has a right to use is Ihe lesser of sdd level of Ihe first sa:vice*s 
capabiHties that the cUent is authorized to use and said set of desked cq)abiMes. 

15 47. The carrier medium as recited in clahn 33, wherein said usmg said capability credential to access one or 
more of said portion of the first services capabilities comprises tiie cUent sending a message to the first service to 
access a fi^ capability, v/hctcm the message includes said capability credential so tot the first service may 
autiienticate said capability credential received m the message to verify that die client has the right to use said first 
capability. 

20 
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